DELETE应该是幂等的。
如果我删除http://example.com/account/123它将删除该帐户。
如果我再次这样做，我会期待404，因为该帐户不再存在？如果我尝试删除从未存在过的帐户怎么办？
在所有情况下（除了错误问题 - 见下文），该帐户不再存在。
来自here
“方法也可以具有”幂等“的属性（除了错误或过期问题）N> 0个相同请求的副作用与单个请求的相同。方法GET，HEAD，PUT和DELETE共享另外，方法OPTIONS和TRACE不应该有副作用，因此本质上是幂等的。“
关键位是N> 0个相同请求的副作用与单个请求相同。
您可以正确地期望状态代码不同但这不会影响幂等性的核心概念 - 您可以多次发送请求而无需对服务器状态进行其他更改。
幂等是关于请求的效果，而不是关于您获得的响应代码。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2说：
方法也可以具有“幂等”的属性（除了错误或到期问题）N> 0个相同请求的副作用与单个请求相同。
虽然您可能会得到不同的响应代码，但可以认为向同一资源发送N + 1个DELETE请求的效果是相同的。
重要的区别在于，幂等性是指副作用，而不是所有效应或反应。如果您执行DELETE http://example.com/account/123，则效果是帐户123现在已从服务器中删除。这是唯一的影响，唯一的变化是服务器的状态。现在假设您再次执行相同的DELETE http://example.com/account/123请求，服务器将以不同的方式响应，但其状态是相同的。
它不像DELETE请求决定以不同的方式更改服务器状态，因为帐户丢失，例如删除另一个帐户或留下错误日志。不，你可以调用相同的DELETE请求一百万次，你可以确定服务器处于与你第一次调用它时相同的状态。
是。无论响应代码如何。
来自latest RFC for HTTP 1.1（强调我的）：
幂等方法是有区别的，因为如果在客户端能够读取服务器响应之前发生通信故障，则可以自动重复请求。例如，如果客户端发送PUT请求并且在收到任何响应之前关闭了底层连接，则客户端可以建立新连接并重试幂等请求。它知道重复请求将具有相同的预期效果，即使原始请求成功，尽管响应可能不同。
它明确表示响应可能不同。更重要的是，它指出了概念的原因：如果一个动作是幂等的，那么客户端可以在遇到任何错误时重复动作，并且知道它不会因为这样做而崩溃;如果没有，客户端必须在安全地重复操作之前进行额外的查询（可能是GET）以查看前一个查询是否有效。只要服务器能够做出这样的保证，该动作就是幂等的。来自another comment的报价：
计算幂等性是关于系统的稳健性。由于事情可能会失败（例如网络中断），当检测到故障时，您如何恢复？最简单的恢复是再次执行，但只有再次执行才是幂等的。例如。
discard(x)是幂等的，但pop()不是。这都是关于错误恢复的。
我认为同样的事情，404 - 帐户不存在。
你可以争辩400 - 不良请求。但就REST而言，您请求执行操作的对象不存在。这意味着404。