저는 REST 인터페이스를 설계하고 있는데 삽입/업데이트/삭제 동사가 반환해야하는 내용 (응답의 내용)에 따라 당황 스럽습니다. api/invoices에 접근 Invoice 기관에 대한 inteface을을 고려해컬렉션, 항목, 동사 및 REST 인터페이스 디자인 : POST가 반환해야하는 항목은 무엇입니까?
GET /api/invoices송장의 목록을 반환GET /api/invoices/123반환 ID 123POST /api/invoices와 송장 (서버에서 생성 ID) 새로운 송장을 추가POST /api/invoices/123ID가있는 인보이스 123DELETE /api/invoices/123는 ID가 123 인 송장을 삭제합니다.
첫 번째 두 메소드가 반환해야하는 것은 꽤 분명하지만 삽입/업데이트/삭제 방법은 어떻습니까? 분명한 대답은 add은 새로 생성 된 항목 (즉, GET/api/invoices/id와 정확히 같은 응답)을 반환해야하고, update은 업데이트 된 항목 (다시 GET과 동일)을 반환해야하고 delete은 아마도 아무 것도 반환하지 않아야합니다. 빈 내용). 이것은 모두 의미 있고 합리적입니다.
그러나 Invoice 엔터티만큼 간단하지 않은 항목을 고려할 때 문제가 발생합니다. 예를 들어 add 요청은 항목을 추가 할뿐만 아니라 실제로 추가 작업에 대한 추가 정보를 반환해야합니다. 항목이 수락 (성공), 항목이 중복 (정보가 성공)이고 항목이 무시되었습니다 (예 : 정보로 성공, 나는 세부 사항으로 eneter하지 않을 것이다), 품목은 거절되었다 (실패). 또한 내 경우에는 새로 추가 된 항목에 버킷에 대해 사전 설정된 '응답'정보가 반환되는 것처럼 반환하려는 추가 정보가 있습니다. HTTP 머리글에 모든 여분의 정보를 out-of-band 정보 (200 범위와 심지어 사용자 정의 헤더의 추가 상태 코드와 같은)로 배치하는 것을 고려했지만 해킹이며 '응답'부분은 실제보다 더 클 수 있습니다. 항목 자체. 이제 add 동사가 완전히 새로운 유형의 항목 (상태, 응답, 새 항목의 ID, 전체 새 항목의 perhpas)을 포함하는 항목을 반환하는 것으로 생각합니다. 그것은 확실히 일을 끝내지 만, 나는 전에 가지고 있던 멋진 대칭을 놓친다.
좋은 연습 ('foo'유형의 항목을 추가 할 때 'bar'유형) 또는 6 개월 후에 되돌아보고 고양이를 꺼내기 때문에 내 머리를 당길 수 있습니다. 가방에요? 만약 'foo에 대한 모든 액세스가 foo를 포함하여 add를 포함하여'반환한다면, 클라이언트는 'add'연산 후에 추가 호출을 만들어서 정말로 관심있는 정보 (즉, '응답')를 검색해야합니다.
'해킹'에 대한 내 의견은 맞춤 HTTP 헤더를 추가하는 것에 관한 것입니다. HTTP 상태의 경우 나는 귀하의 의견에 완전히 동의합니다. –