为什么 GET + DELETE 不是幂等的？答案

【问题标题】：Why is GET + DELETE not idempotent?为什么 GET + DELETE 不是幂等的？
【发布时间】：2019-06-30 12:51:40
【问题描述】：

我正在阅读 Leonard Richardson 和 Mike Amundsen 的 RESTful Web APIs。在第 11 章中，他们写到了 HTTP/1.1 中的流水线（第 247 页）：

客户端可以通过管道传输任何一系列的幂等 HTTP 请求，只要该系列作为一个整体也是幂等的。 […]

我将通过管道发送两个请求。首先，我将检索资源的表示，然后我将删除该资源：

GET /resource

DELETE /resource

GET 和 DELETE 是幂等的，但它们的组合不是。如果在我发送这些请求后出现网络问题，并且我没有从管道中获得第一个响应，我将无法再次发送请求并获得相同的结果。该资源将不再存在。

在我的理解中，幂等性是指多次发送请求后，资源状态与只发送一次请求后的状态相同。在这种特殊情况下，资源状态保持不变，因为在第二次请求后资源仍然被删除。

为什么作者将这种请求组合称为非幂等的？

【问题讨论】：

标签： rest http

【解决方案1】：

"idempotent" and "safe" 条款适用于单个请求。这里的作者决定它也适用于多个请求。

为了理解他们的意思，你必须了解他们的意图。完成请求的流水线化以减少延迟。因此，客户端应用程序的开发人员准备并通过同一连接连续触发 GET 和 DELETE，而无需等待第一个响应。

他们这样做的前提是成功接收到对 GET 的响应，之后可以安全地执行 DELETE。假设客户端应用程序必须读取 GET 响应，例如，将其存储在本地，之后可以丢弃服务器版本。

现在，如果由于某种原因在客户端读取对 GET 请求的响应之前连接丢失，服务器上的资源仍将被删除 - 客户端将无法通过重试请求来获取资源.所以从这个意义上说，这种请求组合不被认为是“幂等的”。

【讨论】：

据我理解，幂等性是指资源状态。参见例如this SO answer。但是，是的，我不应该坚持确切的定义。
是的，但是在这种情况下，无论您重试这些操作多少次，资源仍然会被删除，无论客户端是否读取响应。

【解决方案2】：

你说得对，系统状态是一样的，但听起来他们用这个词来指出客户的观点是不一样的。（即 GET 上的第二次响应将是 404 而不是 200。）我认为您对“幂等”的解释更好，但我也可以理解他们试图提出的观点。

【讨论】：

那么单个 DELETE 也必须被认为不是幂等的。我想知道，因为在本书的其余部分他们都正确使用了这个词。
好点。尽管有些人在 DELETE 上使用 200，即使没有找到，也正是出于这个原因。