1
현재 전송할 리소스가있는 프로젝트에서 작업 중입니다.REST API - 일반 또는 특정 리소스
URI가 POST 동사와 함께 http://api.somename.com/thingssender처럼 보인다고 가정 해 보겠습니다.
시간이 지남에 따라 페이로드에는 한 가지 유형의 전송에만 적용되는 여러 '선택적'요소가있는 자원이되었습니다.
현재이 리소스는 두 가지 유형의 항목 (ThingA 및 ThingB)을 처리하지만 하위 요소의 내용도 다릅니다. 예를 들어 많은 사람들이나 한 가지 일을 사람들에게 보낼 수 있습니다.
ThingC가 필요하다는 것이 요구되었습니다. 이 엔드 포인트가 페이로드의 선택적 데이터로 미래의 ThingD를 차지할 것으로 예상되므로이 '캐치 올'리소스에 의문을 갖기 시작했습니다.
리소스가 개발자뿐만 아니라 REST API를 사용하는 클라이언트에서도 계속 복잡해질 것으로 우려됩니다. 나에게 이것은 혼란을 야기 할뿐 아니라 개발자와 클라이언트 모두에게 최상의 경험을 선사하지 않는다.
일반 엔드 포인트와 특정 엔드 포인트를 작성할 때 사람들이 생각하는 것은 무엇입니까?
그래서 ThingC (http://api.somename.com/ThingsCSender)를 보내는 특정 종점. 그것은 나에게 하나의 책임이 있다고 비명을 지르고 기본 구현에 대한 신중한 고려를 통해 반복되는 기능을 유발해서는 안됩니다.
(주어진 예제는 프로젝트의 실제 개념이나 자원되지 않습니다! p)를
건배