REST에서 종속 리소스를위한 디자인 패턴

Question

리소스 URI에 대한 specs doc을 개발 중입니다. 대부분의 것은 넷즈에서 매우 잘 논의되고 있으며 모두 매우 도움이됩니다. 그러나, 나는 의존적 인 자원을위한 패턴에 조금 머물러있다. 따라서 종속 리소스은 부모 리소스의 즐거움에 존재하는 것입니다. 부모가 존재하지 않으면 부양 가족도 사라집니다. 따라서 책이 있다면 책의 수는 부양 자원이됩니다. 어떤 주어진 질의에 대해서, 책이 없다면 카운트가 없을 것입니다. 말하자면, 저자와 다른 점은 ... 책이 없어도 저자가 있습니다. 승인. 그래서 나는이 URI와 반환 된 데이터

http://example.com/books.json?author=Homer 

{"books": [ 
    {"id": 33, "title": "Iliad", "author": "Homer", "pubyear": "800 BC"}, 
    {"id": 33, "title": "Odyssey", "author": "Homer", "pubyear": "750 BC"} 
]} 

URI가 일반 명사의 복수 버전에서 종료하고, QUERY_STRING이 반환 세트를 필터링하는 데 사용됩니다 같은 있습니다. 반환 "해시"의 루트 노드는 쿼리 된 공통 명사이며 키는 각 요소가 키/값 쌍이있는 해시 인 배열입니다. 정말

http://example.com/books.json/count?author=Homer or 
http://example.com/books.json?aggregate=count&author=Homer 

제안해야한다 개수를 들어

, 내 본능은

http://example.com/books/count.json?author=Homer 

{"books": [ 
    {"count": 2} 
]} 

또는 그러나, 그것은 올바른 방법을 보인다 심지어

http://example.com/books/stats.json?author=Homer 

{"books": [ 
    {"stats": { 
     "count": 2, 
     "units": 10, 
     "sold": 3 
    } 
]} 

다음을 수행하는 것입니다 , 생각?

Answer 1

두 가지 모두 이상하게 느껴지는 이유는 ".json"을 넣어서 콘텐츠 형식과 콘텐츠 식별자를 혼합한다는 것입니다. 콘텐츠 유형은 요청의 "수락"헤더에 있어야합니다. ".json"을 제거하면 고려중인 두 가지 가능성이 같은 것으로 줄어 듭니다.

그건 순정 한 대답입니다. 어떤 이유로 확장 (프레임 워크 또는 클라이언트 제한 사항)을 사용해야하는 경우 마지막 경로 요소에 확장을 적용하는 것이 더 표준 적입니다.