RESTful 하위 유형 리소스

모범 사례 질문. RESTful 인터페이스를 설계한다면 어떻게 서브 타입을 구별 할 수 있을까? 예 : 귀하의 응용 프로그램에는 개와 조류의 하위 유형이있는 동물 (각 동물은 animalId로 식별 됨)이 있으며 각 하위 유형에는 특정 하위 자원이 있습니다. 예 : 개는 꼬리 길이와 새 날개 길이를 가지고 있습니다. 이 중 무엇을 선택 했습니까?RESTful 하위 유형 리소스

1) 
/animals/{animalId}/tail-length (400 when animal is bird) 
/animals/{animalId}/wings-length (400 when animal is dog) 

2) 
/dogs/{animalId}/tail-length 
/birds/{animalId}/wings-length 

3) 
/animals?type=dog/{animalId}/tail-length 
/animals?type=bird/{animalId}/wings-length

출처

2012-01-08 d1x

다른 하위 클래스간에 ID 담합이 없다고 가정하면 다음을 권장합니다. 이 같은 응답

GET /animals/:id

. (이 예제는 JSON이지만 XML/etc처럼 쉽게 할 수 있습니다)

{ 
    "id": "xyz", 
    "type": "dog", 
    "tailLength" 400 
}

이렇게하면 간단하고 RESTful합니다.

출처

2012-01-09 22:30:00 abraham

+1 단순함이 이깁니다. – cmbuckley

좋아, 이것에 동의한다. 다른 질문. 어떤 특별한 유형의 부제를 가지고있는 것은 어떨까요? 예 :/animal/: id/subentity/: sid (예를 들어 개만 있습니다). 그럼 신분증에 속하는 동물이 새라면 400이나 ...? – d1x

이것은 404 여야합니다. – cmbuckley

정말 개인적인 취향의 문제입니다.

개인적으로 옵션 3과 같이 쿼리 문자열에 정보를 넣는 것을 피합니다. 비 계층 적 정보에 쿼리 문자열을 사용하는 경향이 있기 때문입니다. (this question에 허용 대답은 가장 upvoted 대답은 정말 중요하지 않습니다한다고 반면 처음 두가 더 정확 있다고 말한다.) 프록시가 쿼리를 포함하는 리소스를 캐시하지 않을 수 있습니다으로

캐싱, 또한 요인이다 문자열 (Google's advice on leveraging proxy caches 참조).

리소스의 계층 구조를 나타 내기 위해 두 번째 또는 아마도 하이브리드 (/animals/dogs/...)를 선택 하겠지만, 귀하에게 달려 있습니다.

출처

2012-01-08 21:30:09 cmbuckley

RESTful 하위 유형 리소스

답변

관련 문제