REST API의 적절한 디자인은 논란의 여지가있는 주제 인 것 같습니다. 내가 이해하는 한, ID에 대한 순수한 접근 방식은 URL이 외부 세계에 대한 유일한 리소스 식별자이므로 클라이언트가 어떤 식 으로든 URL을 해석 할 필요가 없다는 것입니다 (예 : 최신 segment는 id 임) 간단한 GET 요청에 대해 반환 된 표현에 id를 명시 적으로 포함 할 필요도 없습니다.
클라이언트가 ID를 기반으로 URL을 생성하는 데 신경을 쓸 필요가 없기 때문에 언뜻보기에 이것은 좋은 규칙 인 것 같습니다. ID는 리소스를 검색하는 방법을 알려줍니다. 그러나 이것이 실제로 실제로 적용 가능한지 의심 스럽습니다. 내 마음에 떠오르는 몇 가지 우려 :
/books?author=short.author.id소비자가 ide를 그렇게 해석해서는 안되기 때문에 실제로 거기에 속하지 않는 id에 너무 많은 정보를 넣습니다.
이것은 실제로 실제로 수행됩니까? 이 패턴을 적용하는 인기있는 공용 API의 예가 있습니까? 아니면 내가 그것을 올바르게 이해하지 못하고 이것이 REST 순수 주의자들이 옹호하는 것이 아닐 수도 있습니다.
Hypermedia Driven RESTFul API를 살펴보십시오. HATEOAS에서 URI는 검색 가능하며 문서화되지 않으므로 변경할 수 있습니다. 즉, 시스템의 진입 점이 아닌 경우 ( Cool URIs , 클라이언트가 하드 코딩 할 수있는 유일한 항목)-나머지 부분을 발전시킬 수있는 기능을 원한다면 너무 많으면 안됩니다. 향후 시스템의 URI 구조. 이것은 실제로 REST 의 가장 유용한 기능 중 하나입니다 .
나머지 비 Cool URI의 경우 시간이 지남에 따라 변경 될 수 있으며 API 문서에는 하이퍼 미디어 순회를 통해 런타임시 발견되어야한다는 사실이 명시되어 있어야합니다.
Richardson의 성숙도 모델 ( 레벨 3 )을 살펴보면 링크가 작동하게됩니다. 예를 들어 최상위 수준에서 / api / version (/ 1)이라고하면 그룹에 대한 링크가 있음을 알 수 있습니다. HAL Browser 와 같은 도구에서 이것이 어떻게 보이는지 다음과 같습니다 .
뿌리:
{
"_links": {
"self": {
"href": "/api/root"
},
"api:group-add": {
"href": "http://apiname:port/api/group"
},
"api:group-search": {
"href": "http://apiname:port/api/group?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}"
},
"api:group-by-id": {
"href": "http://apiname:port/api/group/{id}" (OR "href": "http://apiname:port/api/group?id={id}")
}
}
}
여기서 장점은 클라이언트가 관계 (링크) 이름 (리소스 구조 / 속성 외에 분명히 알 수 있음) 만 알면되는 반면, 서버는 관계 (및 리소스) URL을 대부분 자유롭게 변경할 수 있다는 것입니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다