幂等性指的是请求完成后系统的状态

在所有情况下(除了错误问题-见下文)，该帐户不再存在。

从这里

方法也可以具有的属性 “幂等性”(除了 错误或过期问题) 副作用N > 0相同 请求与单个请求相同 请求。方法GET, HEAD, PUT 和DELETE共享此属性。同时, 方法OPTIONS和TRACE应该 没有副作用，所以 本质上是等幂的。”

关键是N个>个相同请求的副作用与单个请求相同。

您期望状态码会有所不同是正确的，但这并不影响等幂的核心概念——您可以多次发送请求，而无需对服务器的状态进行额外更改。

假设我们必须管理以id、名称和城市表示的足球队。

{
    id: "1",
    name: "manchester united",
    city : "manchester "
}

说DELETE是幂等的意味着如果多次调用DELETE /team/1，系统的状态保持不变(实际上第一次调用DELETE /team/1会删除团队)。换句话说，DELETE是幂等的，因为重复调用保持系统状态不变。

同样地，我们可以说PUT也是等幂的。 假设你做了不止一次PUT:

PUT /team/1
{
    id: "1",
    name: "liverpool",
    city : "liverpool"
}

这种PUT请求的重复调用总是具有相同的效果(球队1将是利物浦)。

很明显，GET请求也是幂等的。

我也是这么想的，404 -账户不存在。

你可以争辩400 -坏请求。但是在REST的意义上，您请求执行操作的对象并不存在。这意味着404。

幂等性是关于请求的效果，而不是你得到的响应代码。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html sec9.1.2说:

方法也可以具有的属性 “幂等性”(除了 错误或过期问题) 副作用N > 0相同 请求与单个请求相同 请求。

虽然您可能会得到不同的响应代码，但可以认为向同一资源发送N+1个DELETE请求的效果是相同的。

引用自我对另一个问题的回答:

Historically, RFC 2616, published at 1999, was the most-referenced HTTP 1.1 specs. Unfortunately its description on idempotency was vague, that leaves room for all these debates. But that specs has been superseded by RFC 7231. Quoted from RFC 7231, section 4.2.2 Idempotent Methods, emphasis mine: A request method is considered "idempotent" if the intended EFFECT ON THE SERVER of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent. So, it is written in the specs, idempotency is all about the effect on the server. The first DELETE returning a 204 and then subsequent DELETE returning 404, such different status code does NOT make the DELETE non-idempotent. Using this argument to justify a subsequent 204 return, is simply irrelevant. OK so it is not about idempotency. But then a follow-up question may be, what if we still choose to use 204 in subsequent DELETE? Is it OK? Good question. The motivation is understandable: to allow the client to still reach its intended outcome, without worrying about error handling. I would say, returning 204 in subsequent DELETE, is a largely harmless server-side "white lie", which the client-side won't immediately tell a difference. That's why there are people doing that in the wild and it still works. Just keep in mind that, such lie can be considered semantically weird, because "GET /non-exist" returns 404 but "DELETE /non-exist" gives 204, at that point the client would figure out your service does not fully comply with section 6.5.4 404 Not Found.

But then, the intended way hinted at by RFC 7231, i.e. returning 404 on a subsequent DELETE, shouldn't be an issue in the first place. Many more developers choose to do that. That is presumably because, any client which implements HTTP DELETE (or any HTTP method, for that matter), would not blindly assume the result would always be successful 2xx. And then, once the developer starts to consider the error handling, 404 Not Found would be one of the first errors that comes to mind. At that point, he/she would hopefully draw a conclusion that it is semantically safe for an HTTP DELETE operation to ignore a 404 error. Problem solved.

重要的区别是，幂等指的是副作用，而不是所有的效应或反应。如果执行DELETE http://example.com/account/123，则结果是帐户123现在已从服务器上删除。这是唯一的效果，服务器状态的唯一变化。现在假设您再次执行相同的DELETE http://example.com/account/123请求，服务器将以不同的方式响应，但其状态是相同的。

这并不像DELETE请求决定以不同的方式改变服务器状态，因为帐户丢失了，比如删除另一个帐户，或留下一个错误日志。不，您可以调用相同的DELETE请求一百万次，并且可以确保服务器处于与您第一次调用它时相同的状态。