REST 자원이 단수이고 복수 인 것이 합리적입니까?

다음과 같은보다 전통적인 레이아웃이 아닌지 궁금합니다.

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

예를 들어 단수 및 복수를 사용하는 것이 더 유용합니까?

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

따라서 제품 모음을 만들려면 다음을 수행하십시오.

POST api/Products {data: filters} // returns api/Products/<id>

그런 다음 참조하기 위해 다음을 수행 할 수 있습니다.

GET api/Products/<id> // returns array of products

내 생각에, 이런 식으로 일을 할 때의 주요 이점은 제품 모음을 쉽게 캐싱 할 수 있다는 것입니다. 예를 들어, 제품 콜렉션에 1 시간의 수명을 두어 서버의 호출을 크게 줄일 수 있습니다. 물론, 나는 현재 이런 식으로 일하는 것의 좋은 면만을보고 있습니다. 단점은 무엇입니까?

컬렉션이 api와 상호 작용하는 가장 유용한 방법이 될 때 종종 단일 멤버를 가진 컬렉션으로 생각하는 것이 더 간단 할 수 있습니다. 그런 다음 나중에 싱글과 상호 작용하기 위해 API를 노출하려면 커버 아래에서 해당 멤버가있는 컬렉션으로 전달 된 싱글을 변환하고 다른 API의 동일한 구현을 사용하면됩니다.

여기서 말하는 것은 컬렉션이 상호 작용 메커니즘이되고 컬렉션 전용 API로 시작하고 시스템이 완료된 후 다른 API는 인터페이스 레이어에서 간단한 보조 첨부입니다. 특히 유용합니다. 그러나 YAGNI를 적용하고 원하는 싱글 인스턴스에 대해 컬렉션 인터페이스를 사용하기에 충분할 정도로 유용성이 적다는 것을 알 수 있습니다.

단점은 호출 프로그램도 리소스 이름을 복수화해야한다는 것입니다. 이는 복수형 메커니즘이 내장되어 있지 않은 클라이언트 언어에는 까다로울 수 있습니다. 단수로 남겨두면 호출자가 클라이언트 라이브러리의 코드 생성을 자동화하는 것이 더 쉽습니다.

이를 완화하려면 REST 서비스 용 SDK를 직접 생성 할 수 있습니다. 또는, 당신은 단지 의견을 제시하고 불만을 처리 할 수 ​​있습니다 :)