REST DELETE真的是幂等的吗？

Question

DELETE应该是幂等的.

如果我删除http://example.com/account/123,它将删除该帐户.

如果我再次这样做,我会期待404,因为该帐户不再存在？如果我尝试删除从未存在过的帐户怎么办？

Answer 1

Idempotence是指请求完成后系统的状态

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

从这里开始

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

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

您可以正确地期望状态代码不同但这不会影响幂等性的核心概念 - 您可以多次发送请求而无需对服务器状态进行其他更改.

Answer 2

幂等是关于请求的效果,而不是关于您获得的响应代码.

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

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

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

Answer 3

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

它不像DELETE请求决定以不同的方式更改服务器状态,因为帐户丢失,例如删除另一个帐户或留下错误日志.不,你可以调用相同的DELETE请求一百万次,你可以确定服务器处于与你第一次调用它时相同的状态.

Answer 4

引用我这里的另一个答案：

从历史上看，1999 年发布的 RFC 2616 是引用最多的 HTTP 1.1 规范。不幸的是，它对幂等性的描述是模糊的，这为所有这些争论留下了空间。但该规范已被RFC 7231取代。引自RFC 7231, section 4.2.2 Idempotent Methods，强调我的：

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

所以，它写在规范中，幂等性是关于对服务器的影响。第一个 DELETE 返回 204，然后随后的 DELETE 返回 404，这种不同的状态代码不会使 DELETE 非幂等。使用这个论点来证明随后的 204 返回是完全不相关的。

好的，所以这与幂等性无关。但是接下来的一个问题可能是，如果我们在后续的DELETE中仍然选择使用204呢？可以吗？

好问题。动机是可以理解的：允许客户端仍然达到预期的结果，而不必担心错误处理。我会说，在随后的 DELETE 中返回 204，在很大程度上是无害的服务器端“善意的谎言”，客户端不会立即分辨出区别。这就是为什么有人在野外这样做并且它仍然有效。请记住，这样的谎言在语义上可以被认为是奇怪的，因为“GET /non-exist”返回 404 而“DELETE /non-exist”给出 204，此时客户端会发现您的服务不完全符合第 6.5.4 节 404 未找到。

但是，RFC 7231 暗示的预期方式，即在随后的 DELETE 中返回 404，首先不应该成为问题。更多的开发人员选择这样做。这大概是因为，任何实现 HTTP DELETE（或任何 HTTP 方法，就此而言）的客户端都不会盲目地假设结果总是成功 2xx。然后，一旦开发人员开始考虑错误处理，404 Not Found 将是第一个想到的错误之一。在这一点上，他/她希望得出结论，HTTP DELETE 操作忽略 404 错误在语义上是安全的。问题解决了。

Answer 5

来自HTTP RFC:

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

注意这是"副作用",而不是"反应".

Answer 6

是的。无论响应代码如何。

来自HTTP 1.1 的最新 RFC（强调我的）：

幂等方法的区别在于，如果在客户端能够读取服务器的响应之前发生通信失败，则可以自动重复请求。例如，如果客户端发送 PUT 请求，并且在收到任何响应之前底层连接已关闭，则客户端可以建立新连接并重试幂等请求。它知道重复请求将具有相同的预期效果，即使原始请求成功，但响应可能不同。

它明确表示响应可能会有所不同。更重要的是，它指出了这个概念的原因：如果一个动作是幂等的，客户端可以在遇到任何错误时重复该动作，并且知道这样做不会导致任何崩溃；如果没有，客户端将不得不进行额外的查询（可能GET）以查看前一个是否有效，然后才能安全地重复操作。只要服务器能做出这样的保证，动作就是幂等的。引用另一条评论：

计算幂等性与系统的健壮性有关。由于事情可能会失败（例如网络中断），当检测到故障时，您如何恢复？最简单的恢复是再做一次，但只有在再次做是幂等的情况下才有效。例如discard(x)是幂等的，但pop()不是。这都是关于错误恢复的。

Answer 7

id假设我们必须管理以、name和为代表的足球队city。

{
    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请求也是幂等的。