추가 리소스가있는 RESTful 컬렉션을위한 적절한 경로 패턴

Question

제 3 자 노출 및 소모에 대한 RESTful API를 수행해 왔으며 여기 저기에 두 가지 패턴이 나타납니다. 각각에는 찬반 양론이 있으며 내 생각에는 "깨끗합니다".

컬렉션 리소스 (예 : "assets")가 있고 컬렉션 내의 일부 리소스 (예 : 집계 된 뷰 엔드 포인트 또는 일부 명령과 같은 애셋이 아닌 컬렉션 자체의 하위 리소스)를 노출하려는 상황이 있습니다.). 내가 볼

두 패턴은 다음과 같습니다

1. 사람들은 /assets/${asset-id} 같은 편안한 수집 자원을 작성하고이 GET /assets/owned, GET /assets/summary, POST /assets/recheck-inventory처럼 필요한 다른 모든 것들에 노출됩니다. 이는 깔끔하고 간결 해 보이지만 ${asset-id}과 하위 리소스 URL의 명사 (예 : asset12345 및 summary은 URL의 동일한 위치에 있음) 사이에 충돌이 발생합니다.

2. 기타는 /assets/items/${asset-id}이고 모두 GET /assets/owned, GET /assets/summary 등의 모든 것을 노출합니다. 이것은 라우팅 관점과 좀 더 미래 지향적 인 것으로부터 더 깨끗하지만 경로에 여분의 명사를 추가합니다. 사람들이 예를 들어 POST /assets을 할 때 혼란을 겪습니다.

지금까지 살펴본 "모범 사례"지침은 질문을 완전히 피합니다. 나는 또한 REST가 표준이 아닌 컨벤션이며, 보편적 인 "it depends"대답이라는 것을 알고있다. 그래도 일반적인 권장 사항이있는 것처럼 느껴집니다.

따라서 질문은 두 가지 중 어느 것을 사용합니까?

업데이트 : 명확히 우리가 가정 있도록 :

• /assets/owned는 다른 유형이 아닌 자산의 실체를 포함, 그것은 쿼리되지 않도록 당신은/POST/GET 그것에서 항목을 삭제할 수 있습니다.
• /assets/summary
(즉, POST 만 해당) 또한

, 우리는 REST의 원칙을 고수하려는 통합 문서 (예를 들어 수량과 예를 들어 보고서)

/assets/recheck-inventory 명령입니다 :

• 경로 경로는 엔티티와 그 상태를 유일하게 식별해야한다.
• 쿼리 매개 변수는 반환되는 요소를 변경하지만 페이로드 형식은 변경하지 않습니다.
• 헤더 프로토콜 수준의 정보이며, 나도이 방법을 좋아하지만, 인식하지 않는

Answer 1

서비스 로직 (즉, 프리젠 테이션, 보안, 캐싱 등)을 변경하지 마십시오, 그 REST하지 않습니다 URI 구조를 설계하는 방법에 제약 조건을 두어 올바른 느낌을 줄 수 있습니다. 분명히이 웹 서비스의 개발자들은이 접근법을 올바르게 느꼈습니다.

플랫 URI가 훨씬 낫기 때문에 다음과 같이 URI를 사용합니다.

/assets/items/${asset-id} 
    -> /assets/${asset-id} 
/assets/owned 
    -> /assets/?owned 
    -> /assets/?owned=true 
/assets/summary 
    -> /assets-summary 
    -> /assets/ + "Prefer: return=minimal" 

당신은 prefer header here에 대한 자세한 내용을 찾을 수 있습니다,하지만 당신은 당신이 그것을 보조 캐시 열쇠가 될하려는 경우 vary header하여 등록 할 필요가 있다는 인식 될 수

.