계층 구조에서 다른 위치를 차지하는 리소스의 URI를 디자인하는 방법은 무엇입니까?

Question

목록 리소스를 다른 리소스가 "소유"할 수있는 가장 좋은 방법은 무엇입니까?

일반적인 블로그 예를 들어보세요.

게시물, 댓글 및 사용자가 있다고합시다. 게시물은 많은 의견을 가지고 있으며 사용자는 많은 의견의 저자입니다.

주어진 게시물 (예 : 해당 게시물의 모든 댓글) 또는 모든 댓글, 기간에 대해 주어진 사용자의 컨텍스트 (예 : 해당 사용자의 댓글 작성 내역) 내에서 댓글 목록을 얻길 원할 수 있습니다. (끔찍한 일은 아니지만). 이 확인

/user/user_id/comments 
/post/post_id/comments 
/comments 

인가 :

당신은 세 가지 다른 URI를 가질 수있다? 내 이해는 URI가 멱등수가되어야한다는 것입니다. 단일 URL을 사용하는 것이 "RESTful"입니까? /설명

및 필터링 매개 변수를 전달 하시겠습니까? 예 :

/comments?user=user_id 
/comments?post=post_id 

나는이 두 번째 방법은 당신이 또한

/comments?user=user_id&post=post_id 

와 사용자 및 우편으로 필터링 할 수 있습니다 의미 생각하지만 첫 번째 예는 계층 적 컨텍스트를 노출하는 방법을 좋아한다.

여기에서 가장 좋은 방법은 무엇입니까?

Answer 1

첫 번째 예가 나에게 더 나을 것 같습니다. 귀하의 서비스가 링크 된 데이터를 통해 탐색 가능해야한다는 더 큰 요점을 잊지 마십시오. 그래서 만약 내가 /user/123에 가면에 대한 링크 [href, a]가 나에게 그 URI에있는 서비스의 다른 부분을 알려줍니다.

Answer 2

내 이해는 URI가 멱등수가되어야한다는 것입니다.

URI는 조작이 아니므로 멱등 원으로 설명 될 수 없습니다. Idempotency는 단순히 동일한 작업을 두 번 수행하면 시스템의 최종 상태가 작업을 한 번 수행 한 것과 동일하다는 것을 의미합니다. 반면에 URI에 대한 HTTP 요청은 멱등 수 있지만 모든 요청이있을 필요는 없습니다. 예를 들어, HTTP PUT 및 DELETE는 이 항상이어야하며 멱등 원이어야합니다. 그러나 HTTP POST는 그렇지 않을 수도 있습니다. HTTP GET은 시스템의 상태를 변경하지 않아야합니다.

친숙한 URI 디자인 (REST에 접함)에 대한 질문으로 쿼리 매개 변수를 사용하는 것이 좋습니다. 일반적으로 몇 가지 큰 리소스 세트를 하위 선택합니다 (예 : 페이지 매김 및/또는 검색. 이 경우에 /user/{user_id}/comments는 완벽하게 정상입니다. 그러나 URI의 데이터베이스 키 노출에 대해서는 권장하지 않습니다. 이는 현재 구현을 초과하여 URI가 나중에 변경되지 않도록 보장하기 위해 숨겨야하는 구현 세부 사항입니다. user_id 값의 경우 사용자 이름과 같은 다른 고유 한 값을 사용하는 것이 좋습니다.