最近我花了很多时间阅读HTTP 1.1规范并将其与REST相关联。关于HTTP DELETE方法的“幂等性”和安全性，我发现有两种解释。这里是两个不同的观点：
如果你使用HTTP DELETE删除一个资源，并且它成功（200 OK），然后你尝试N次删除该资源，每一次删除调用都应该返回成功消息（200 OK）。这就是它的“幂等性”。
如果你使用HTTP DELETE删除一个资源，并且它成功（200 OK），然后你再次尝试删除该资源，你应该得到错误消息（410 Gone），因为资源已被删除。
规范说DELETE是幂等的，当然，但它也说幂等事件序列仍然可以产生副作用。我真的觉得第二个观点是正确的，第一个观点是误导人的。让客户端认为他们是先前删除资源的原因，我们引入了什么“安全性”呢？
有很多人属于第一个阵营，包括几位作者在内，所以我想确认除了情感之外是否还有其他令人信服的理由让人们倾向于第一个阵营。
幂等并不意味着请求不能有副作用（这是“safe”的属性描述的），它只是意味着多次发出相同的请求不会产生不同或附加的副作用。
在我看来，随后的DELETE请求应该返回错误-它仍然是幂等的，因为服务器的状态与仅进行一次DELETE请求时相同。但是，返回200 OK状态也应该没有问题-我认为幂等不要求对随后的DELETE请求返回错误代码，只是返回错误状态似乎更有意义。
@MichaelBurr关于幂等性和副作用的观点是正确的。
我的看法是，在给定的REST请求中涉及到两个状态，客户端的状态和服务器的状态。REST就是在服务器和客户端之间传输这些状态，使得客户端的状态映射到服务器状态的子集，换句话说，子集与服务器保持一致。因此，幂等性应该意味着后续的幂等请求不会导致任何一个状态与仅发出一次请求时不同。在第一次DELETE操作中，你可以想象服务器删除了资源并让客户端知道它也可以删除资源（因为资源“不再存在”）。现在，两个状态应该与删除前完全相同，只不过少了被删除的项。如果客户端在已经删除该项后尝试删除该项时做出任何不同的操作，则从服务器传输到客户端的状态必须包含不同的信息。服务器可以稍微以不同的方式处理资源已被删除的信息，但一旦它以不同的方式响应，方法的幂等性基本上就被破坏了。
对于幂等函数：
delete(client_state) -> client_state - {item}
delete(delete(client_state)) -> client_state - {item}
delete(client_state) = delete(delete(client_state))
delete(client_state) = send_delete(client_state) -> receive_delete(client_state)
-> respond_to_delete(informative_state)
-> handle_response(informative_state)
-> client_state - {item}
维基百科定义幂等性为：
一个操作可以被多次应用，而不会改变除了初始应用之外的结果。
请注意，他们谈到操作的 结果。对我来说，这包括服务器状态和响应代码 两者。
HTTP规范在这个问题上有些含糊不清。它定义HTTP方法是幂等的：
如果多个相同请求的预期效果与单个请求的预期效果相同，则该请求是幂等的。
如果您将维基百科定义中的 效果 解释为 结果，则它们的意思相同。无论如何，告诉客户端资源已经被删除并没有实际好处。
If-Match-ETag）来处理这种情况。404和410不在其中。因此，请取消您的负评。 - Gili