[http] DELETE 요청 본문에 대한 RESTful 대안

그동안 HTTP 1.1 사양이 보인다 수 에 메시지 본문 DELETE 요청을,에 대한 정의 의미가 없기 때문에 서버가 그것을 무시해야 함을 표시 것으로 보인다.

4.3 메시지 본문

서버는 모든 요청에 ​​대해 메시지 본문을 읽고 전달해야합니다. 요청 메소드가 엔티티 본문에 대해 정의 된 의미를 포함하지 않는 경우 요청을 처리 할 때 메시지 본문을 무시해야합니다 (SHOULD).

나는 이미 다음과 같은이 주제에 대한 몇 가지 관련 토론을 검토했습니다.

• HTTP DELETE 요청에 엔티티 본문이 허용됩니까?
• HTTP 요청 메서드의 페이로드
• 요청 본문이있는 HTTP GET

대부분의 토론은 DELETE에 메시지 본문을 제공하는 것이 허용 될 수 있다는 데 동의하는 것처럼 보이지만 일반적으로 권장되지 않습니다.

또한 DELETE에서 요청 본문을 지원하기 위해 이러한 라이브러리에 대해 점점 더 많은 개선 사항이 기록되는 것처럼 보이는 다양한 HTTP 클라이언트 라이브러리의 추세를 확인했습니다. 대부분의 도서관은 의무가있는 것처럼 보이지만 때로는 약간의 초기 저항이 있습니다.

내 사용 사례에서는 DELETE에 필요한 메타 데이터를 추가해야합니다 (예 : 삭제에 필요한 다른 메타 데이터와 함께 삭제 “이유”). 다음 옵션을 고려했지만 HTTP 사양 및 / 또는 REST 모범 사례와 완전히 적절하고 인라인 된 것은 없습니다.

• 메시지 본문 -사양은 DELETE의 메시지 본문에 의미 값이 없음을 나타냅니다. HTTP 클라이언트에서 완전히 지원되지 않습니다. 표준 관행이 아님
• 사용자 지정 HTTP 헤더 -사용자 지정 헤더를 요구하는 것은 일반적으로 표준 관행에 위배됩니다 . 그것들을 사용하는 것은 내 API의 나머지 부분과 일치하지 않으며 사용자 지정 헤더가 필요하지 않습니다. 또한 잘못된 사용자 정의 헤더 값을 나타내는 데 사용할 수있는 좋은 HTTP 응답이 없습니다 (아마도 별도의 질문 일 것입니다).
• 표준 HTTP 헤더 -적절한 표준 헤더 없음
• 쿼리 매개 변수 – 쿼리 매개 변수를 추가하면 실제로 삭제되는 요청 URI가 변경됩니다. 표준 관행에 반하여
• POST 방법 -(예 POST /resourceToDelete { deletemetadata }) POST는 삭제를위한 의미 론적 옵션이 아닙니다. POST는 실제로 원하는 반대 동작을 나타냅니다 (예 : POST는 리소스 부하를 생성하지만 리소스를 삭제해야 함).
• 다중 메소드 -DELETE 요청을 두 개의 작업으로 분할 (예 : PUT 삭제 메타 데이터, 다음 DELETE)하면 원자 적 작업이 두 개로 분할되어 잠재적으로 일관성없는 상태가 남습니다. 삭제 이유 (및 기타 관련 메타 데이터)는 리소스 표현 자체의 일부가 아닙니다.

내 첫 번째 선호도는 아마도 사용자 정의 HTTP 헤더에 이어 메시지 본문을 사용하는 것입니다. 그러나 표시된대로 이러한 접근 방식에는 몇 가지 단점이 있습니다.

DELETE 요청에 필요한 메타 데이터를 포함하기위한 REST / HTTP 표준과 관련된 권장 사항 또는 모범 사례가 있습니까? 고려하지 않은 다른 대안이 있습니까?