답변:
상태 비 저장 시스템의 HTTP 요청은 독립적이어야하므로 한 요청의 결과가 이전 요청에 의존해서는 안됩니다. 두 사용자가 동일한 리소스에서 동시에 삭제를 수행 한 경우 어떻게되는지 고려하십시오. 두 번째 요청이 404를 얻는 것이 합리적입니다. 한 사용자가 두 번 요청하는 경우에도 마찬가지입니다.
나는 DELETE가 두 가지 다른 응답을 반환하는 것이 멱등하다고 느끼지 않는다고 생각합니다. 멱등 요청을 시스템을 동일한 상태로 남겨 두는 것으로 생각하는 것이 유용하며 반드시 동일한 응답을 가질 필요는 없습니다. 따라서 기존 자원을 삭제하든 존재하지 않는 자원을 삭제하려고하든 관계없이 서버 자원 상태는 동일합니다.
RESTful 웹 서비스 쿡북은이를위한 훌륭한 리소스입니다. 우연히 Google 미리보기 는 DELETE에 대한 페이지를 표시합니다 (11 페이지).
DELETE 메소드는 멱 등성입니다. 이는 서버가 이전 요청에서 리소스를 삭제 한 경우에도 서버가 응답 코드 200 (OK)을 반환해야 함을 의미합니다. 그러나 실제로 DELETE를 멱등 작업으로 구현하려면 서버가 삭제 된 모든 리소스를 추적해야합니다. 그렇지 않으면 404 (찾을 수 없음)를 반환 할 수 있습니다.
나는 현재 선택된 대답이 말한 것에 동의 합니다 .2nd (및 3rd, 4th, ...) DELETE는 404를 받아야합니다 . 그리고 저는 답변이 143 표를 받았지만 반대 의견도 54 표를 받았기 때문에 커뮤니티는 대략 3 : 1 비율로 2 개의 캠프로 나뉩니다. 이 오랜 논쟁을 해결하기 위해 더 많은 정보가 있습니다.
우선, "내"가 생각하는 것, "당신"이 생각하는 것 또는 다른 책 저자가 생각하는 것부터 시작하지 말자. HTTP 사양, 즉 RFC 7231부터 시작하겠습니다.
DELETE /some/resource/which/does/not/exist은 404가되어야합니다. 그런 다음 DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/ago404를 반환 할 수도 있습니다. 그렇다면 왜 DELETE /some/resource/i/deleted/five/seconds/ago달라야합니까? "하지만 멱등 성은 어때?!", 당신이 소리 치는 소리가 들립니다. 잠시만 요, 우리는 그것에 대해 곧 시작합니다.역사적으로 1999 년에 발표 된 RFC 2616은 가장 많이 참조 된 HTTP 1.1 사양이었습니다. 불행히도 멱등성에 대한 설명은 모호 하여 이러한 모든 논쟁의 여지가 있습니다. 그러나 해당 사양은 RFC 7231 로 대체되었습니다. RFC 7231, 섹션 4.2.2 멱 등성 방법 에서 인용 , 내 강조 :
요청 방법은 해당 방법을 사용하는 여러 동일한 요청의 서버에 대한 의도 된 효과가 단일 요청의 효과와 동일한 경우 "멱 등성"으로 간주됩니다. 이 사양에 정의 된 요청 메서드 중 PUT, DELETE 및 안전 요청 메서드 는 멱등 적 입니다.
따라서 사양에 기록되어 있으며 멱등 성은 서버에 미치는 영향에 관한 것입니다. 204를 반환하는 첫 번째 DELETE와 404를 반환하는 후속 DELETE, 이러한 다른 상태 코드는 DELETE를 비멱 등하게 만들지 않습니다. 이 인수를 사용하여 후속 204 수익을 정당화하는 것은 단순히 관련이 없습니다.
좋습니다. 멱등성에 관한 것이 아닙니다. 그러나 후속 질문은 다음 DELETE에서 여전히 204를 사용하도록 선택하면 어떻게 될까요? 괜찮습니까?
좋은 질문. 동기는 이해할 수 있습니다. 클라이언트가 오류 처리에 대해 걱정하지 않고 의도 한 결과에 도달 할 수 있도록하는 것입니다. 후속 DELETE에서 204를 반환하는 것은 서버 측에서 거의 무해한 "하얀 거짓말"이며 클라이언트 측에서는 즉시 차이를 말하지 않습니다. 그렇기 때문에 약 25 %의 사람들이 야생에서 그렇게하고 있으며 여전히 작동하는 것처럼 보입니다. GET /non-exist404를 반환하지만 DELETE /non-exist204를 제공 하기 때문에 그러한 거짓말은 의미 상 이상하다고 간주 될 수 있습니다 . 그 시점에서 클라이언트는 귀하의 서비스가 섹션 6.5.4 404 Not Found를 완전히 준수하지 않는다는 것을 알아낼 것 입니다.
그러나 RFC 7231에서 암시하는 의도 된 방식, 즉 후속 DELETE에서 404를 반환하는 것은 처음에는 문제가되지 않아야한다는 점을 지적하고 싶습니다. 3 배 더 많은 개발자가 그렇게 선택했으며, 404를 처리 할 수없는 클라이언트로 인해 발생하는 중대한 사건이나 불만을들은 적이 있습니까? 아마도, 아니요, 그 이유는 HTTP DELETE (또는 그 문제에 대한 모든 HTTP 메서드)를 구현하는 괜찮은 클라이언트가 결과가 항상 성공할 것이라고 맹목적으로 가정하지 않기 때문입니다. 그런 다음 개발자가 오류 처리를 고려하기 시작하면 404 Not Found가 가장 먼저 떠오르는 오류 중 하나입니다. 이 시점에서 그는 아마도 HTTP DELETE 작업이 404 오류를 무시하는 것이 의미 상 안전하다는 결론을 내릴 것입니다. 그리고 그들은 그렇게했습니다.
문제 해결됨.
첫 번째 삭제 : 200 또는 204.
후속 DELETE : 200 또는 204.
근거 : DELETE는 멱등 적이어야합니다. 두 번째 DELETE에서 404를 반환하면 응답이 성공 코드 에서 오류 코드로 변경 됩니다. 클라이언트 프로그램은 DELETE가 실패했다고 가정하여 잘못된 작업을 수행 할 수 있습니다.
예 :
이 접근 방식의 사용을 설명하기 위해 PayPal 용 HTTP API 스타일 가이드 에는 다음과 같은 가이드 라인이 있습니다.
DELETE : 요청이 리소스를 삭제하고 성공적으로 삭제되었으므로 대부분의 경우 콘텐츠를 반환 할 필요가 없기 때문에이 메서드는 상태 코드 204를 반환해야합니다 (SHOULD).
DELETE 메서드도 멱 등성이 있어야하므로 리소스가 이미 삭제 된 경우에도 여전히 204를 반환해야합니다 (SHOULD). 일반적으로 API 소비자는 리소스가이 작업의 일부로 삭제되었는지 또는 이전에 삭제되었는지는 신경 쓰지 않습니다. 이것이 404 대신 204가 반환되어야하는 이유이기도합니다.