REST API에서 일반 쿼리 조건을 지원하는 단점은 무엇입니까?

Question

REST API가 다양한 쿼리 제약 조건을 지원한다는 점에서 어떤 트레이드 오프가 필요한지 알고 싶습니다. API like that of Parse이하는 일을 생각하고 있습니다.

Parse 's take on REST를 사용하면 클라이언트에서 DB 문을 거의 완벽하게 작성할 수 있습니다. 서버에서 엔진의 where : {} JSON 키를 모두 포함하는 적절한 Mongo 쿼리로 변환한다고 상상합니다. 정의 된 조건. 당신은 데이터 섹션에서 볼 수 있듯이

curl -X GET \ 
    -H "X-Parse-Application-Id: xxx" \ 
    -H "X-Parse-REST-API-Key: xxx" \ 
    -G \ 
    --data-urlencode 'where={"hometown":{"$select":{"query":{"className":"Team","where":{"winPct":{"$gt":0.5}}},"key":"city"}}}' \ 
    --data-urlencode 'limit=200' \ 
    --data-urlencode 'skip=400' \ 
    https://api.parse.com/1/classes/_User 

는 하나이 매우 유연한 시스템을 사용하여 클라이언트에 다소 복잡하고 흥미있는 쿼리를 생성 할 수 있습니다 : 예를 들어, 여기에서 할 수있는 일입니다. 이제 당신이 파스가 아니고, SQL을 사용하고 있고, 개인 (private!) API의 요구 사항이 클라이언트가 만들 수있는 상상할 수있는 모든 유형의 쿼리를 지원하는 것이 아니라 몇 가지 제약 조건을 정의 할 수 있다는 이점이 있습니다 충분한 정밀도로 질의를 정의 할 수 없기 때문에 여기저기서 클라이언트가 사용하지 않을 데이터를 보내지 않도록합니다.

위의 경우 DB 문 생성 엔진 방식이 지나치게 과장되어 있습니까? 그렇다면 다른 리소스가 몇 가지 제약 조건 (제한, 건너 뛰기, 순서 지정)을 공유하지만 모든 리소스를 공유하지 않는 것을 다루는 더 간단한 방법은 무엇입니까? 일부는 해당 자원에만 해당 될 수 있습니다. 다양한 디자인 결정에 대해 이야기하는 훌륭한 자료가 있습니까?

Answer 1

RESTful 아키텍처가 필요한 경우 HATEOAS를 사용해야합니다. 즉, 이전 응답에서 보낸 표현을 기반으로 쿼리를 생성해야합니다. 따라서 "DB-statement-generation engine"은 불필요한 것입니다., 설정할 수있는 모든 옵션은 서버에 의해 템플릿으로 제공됩니다 (예 : HTML 폼, 그러나 아마도 여러분의 경우에는 좀 더 복잡한 것, 아마도 XForms는 사용자 지정 콘텐츠 형식). 제약 조건은 양식 입력 마크 업에 의해 정의됩니다. 클라이언트에 대한 모든 제약 조건을 설명하기에 충분한 마크 업 언어를 선택하십시오.