使用http DELETE删除资源

Question

所以，鉴于Http中的DELETE动词是幂等的，当我发出以下请求时，第二个（或第三个，或第四个等等）会发生什么？

DELETE /person/123

第一次，资源被删除，我返回204（成功，没有内容）。我应该在后续电话或404（未找到）上返回204吗？

Answer 1

由于无状态系统中的HTTP请求应该是独立的，因此一个请求的结果不应该依赖于先前的请求。考虑如果两个用户同时在同一资源上执行DELETE会发生什么。获得404的第二个请求是有意义的。如果一个用户发出两个请求，情况也应该如此。

我猜测让DELETE返回两个不同的响应对你来说并不是幂等的。我认为将幂等请求视为离开系统处于相同状态，而不一定具有相同的响应是有用的。因此，无论您是删除现有资源，还是尝试删除不存在的资源，服务器资源状态都是相同的。

Answer 2

RESTful Web服务手册是一个很好的资源。偶然，its google preview显示有关DELETE（第11页）的页面：

  

DELETE方法是幂等的。这个   意味着服务器必须返回   响应代码200（OK）即使   服务器删除了一个资源   先前的请求。但在实践中，   将DELETE实现为幂等元素   操作需要服务器保留   跟踪所有已删除的资源。   否则，它可以返回404（不是   实测值）。

Answer 3

我同意当前选择的答案，即第二（和第三，第四，...）DELETE应该得到404 。而且，我注意到答案有143票赞成，但也有相反的评论，票数54票赞成，因此该社区按大约3：1的比例分为两个阵营。这里有更多信息可以解决这个长期的辩论。

1. 首先，让我们从“我”的想法，“您”的想法或另一本书的作者的想法开始。让我们从HTTP规范即RFC 7231开始。

   • RFC 7231, section 4.3.5 DELETE碰巧只提到成功的响应应该是2xx，但是它没有指出随后的DELETE将得到什么。因此，让我们深入研究。
   • RFC 7231, section 6.5.4 404 Not Found说404响应是针对不存在的资源。由于没有调用特定的http方法（尤其是DELETE），否则我们可以直观地得到一个印象（正确的说），我的请求DELETE /some/resource/which/does/not/exist应该产生404。然后，{{ 1}}也可能会返回404。那么，为什么DELETE /some/resource/which/happened/to/be/removed/by/someone/else/five/days/ago应该有所不同呢？ “但是，幂等吗？！”，我听到你在尖叫。等等，我们即将开始。

   • 从历史上看，1999年发布的RFC 2616是引用最多的HTTP 1.1规范。不幸的是，its description on idempotency was vague为所有这些辩论留出了空间。但是该规范已被RFC 7231取代。引自RFC 7231, section 4.2.2 Idempotent Methods，重点是我的：

     如果预期的效果为ON，则请求方法被视为“幂等” 使用该方法的多个相同请求的服务器是 与单个此类请求的效果相同。在请求方法中 由该规范，PUT，删除和安全的请求方法定义 是幂等的。

     所以，它写在规范中，幂等性全是关于对服务器的影响。第一个DELETE返回20​​4，然后后续的DELETE返回404，这样的不同状态代码不会使DELETE成为非等幂的。使用此参数来证明随后的204返回是正确的。

2. 好，所以这与幂等无关。但是接下来的问题可能是，如果我们仍然选择在后续的DELETE中使用204，该怎么办？可以吗？

   好问题。动机是可以理解的：允许客户仍然达到预期的结果，而不必担心错误处理。我要说的是，在后续的DELETE中返回204，这在很大程度上是服务器端的“善意谎言”，客户端不会立即告诉别人。这就是为什么约有25％的人在野外这样做的原因，而且它似乎仍然有效。请记住，这种谎言在语义上可能是奇怪的，因为DELETE /some/resource/i/deleted/five/seconds/ago返回404，而GET /non-exist给出了204，这时客户会发现您的服务不完全符合{{3} }。

   但是我想指出的是，RFC 7231所暗示的预期方式，即在随后的DELETE上返回404，首先不应该成为问题。有3倍多的开发人员选择这样做，您是否曾听到由客户端无法处理404引起的重大事件或抱怨？大概没有，这是因为，任何实现HTTP DELETE（或任何HTTP方法）的体面的客户端都不会盲目地假设结果总是成功的2xx。然后，一旦开发人员开始考虑错误处理，“ 404 Not Found”将是第一个想到的错误之一。到那时，他/她可能会得出一个结论，即HTTP DELETE操作忽略404错误在语义上是安全的。他们是这样做的。

问题解决了。

Answer 4

首先删除 ：200或204。

后续DELETE ：200或204.

理由 ：DELETE应该是幂等的。如果您在第二次DELETE时返回404，则您的响应将从成功代码更改为错误代码。客户端程序可能会根据DELETE失败的假设采取不正确的操作。

实施例：

• 假设您的DELETE操作是客户端程序执行的多步操作（或＃34; saga＆＃34;）的一部分。
• 例如，客户端程序可以是执行银行交易的移动应用程序。
• 让我们说客户端程序有一个自动重试DELETE操作（这是有道理的，因为DELETE应该是幂等的）。
• 让我们说第一个DELETE已成功执行，但200响应在前往客户端程序的过程中丢失了。
• 客户端程序将重试DELETE。
• 如果第二次尝试返回404，则客户端程序可能会因为此错误代码而取消整个操作。
• 但由于第一个DELETE在服务器上成功执行，系统可能会处于不一致状态。
• 如果第二次尝试返回200或204，则客户端程序将按预期继续。