RESTFUL API 리소스 중첩 설계 : GET/API/TWEETS/1/댓글 또는 GET/API/COMMING? Tweet_id = 1, 어떤 것이 사양과 더 일치합니까?

RESTFUL API 리소스 중첩 모범 사례 : 트윗 주석을위한 URL 디자인

RESTFUL API를 설계 할 때 자원 관계 처리가 중요합니다. 예를 들어, 특정 트윗에서 모든 주석을 얻고 적절한 URL 설계는 나머지 사양을 반영합니다. 이 기사는 두 개의 URL 설계 체계를 비교하고 장단점을 분석합니다.

tweet_id = 1 모든 주석을 가져와야한다고 가정 해 봅시다. 구성표 1은 GET /api/tweets/1/comments , Scheme은 GET /api/comments?tweet_id=1 .

해결책 1 : GET /api/tweets/1/comments

이 체계는 트윗 리소스에 따라 리소스를 주석하고 URL은 댓글과 트윗 간의 제휴를 직접 반영합니다. GET /api/tweets/1/comments 요청 의도를 명확하게 표현합니다. 1의 tweet_id 있는 트윗에 대한 모든 주석을 가져옵니다. 이는 자원 경로가 나머지 원칙의 리소스 계층을 나타내는 개념을 준수합니다. 특정 주석 (예 : comments_id = 1 )을 가져와야하는 경우 GET /api/tweets/1/comments/1 사용하십시오.

해결책 2 : GET /api/comments?tweet_id=1

이 체계는 쿼리 매개 변수 tweet_id 사용하여 트윗을 지정하며 URL은 중첩 리소스에 액세스하는 것보다 주석 리소스 쿼리와 비슷합니다. 또한 목적을 달성 할 수는 있지만 의견과 트윗 사이의 직접적인 관계를 직접 반영하지는 않으며 URL 시맨틱 표현식은 상대적으로 약합니다. comments_id = 1 으로 주석을 얻으려면 특정 트윗에서 모든 주석의 URL을 얻는 것과는 다른 GET /api/comments/1 사용해야하며 일관성이 부족합니다.

결론 : 플랜 1은 편안한 사양에 따라 다릅니다.

솔루션 1 ( GET /api/tweets/1/comments )은 명확한 자원 표현 능력으로 승리합니다. 그것은 주석 리소스와 트윗 리소스 사이의 제휴를보다 직관적으로 보여주고 편안한 디자인 원칙을 준수합니다. 물론, 삭제중인 주석 리소스의 내결함성을 고려해야하는 경우, 관련 트윗 자원이 여전히 tweet_id 를 통해 찾을 수 있기 때문에 솔루션 2가 더 유리할 수 있습니다. 그러나 이러한 특별한 요구가 없으면 프로그램 1은 편안한 모범 사례를 나타냅니다. GET /api/comments/1 만 사용하여 특정 주석을 얻는 것도 표준 URL 설계이지만 URL 구조 측면에서 체계 1과 일치하지 않습니다.

위 내용은 RESTFUL API 리소스 중첩 설계 : GET/API/TWEETS/1/댓글 또는 GET/API/COMMING? Tweet_id = 1, 어떤 것이 사양과 더 일치합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!