http - 什么是 HTTP 方法中的幂等性？

Question

我已经阅读了 HTTP 文档，但我无法理解什么是幂等性。有人可以帮忙吗？

Answer 1

What is idempotency in HTTP methods?

幂等性 是 HTTP 方法的一个属性。

如果使用该方法的多个相同请求在服务器上的预期效果与效果相同，则该请求方法被视为幂等对于单个这样的请求。值得一提的是，幂等性是关于服务器上资源状态产生的效果，而不是关于收到的响应状态代码由客户。

为了说明这一点，考虑定义为幂等的 DELETE 方法。现在考虑客户端执行 DELETE 请求以从服务器删除资源。服务器处理请求，资源被删除，服务器返回 204。然后客户端重复相同的 DELETE 请求，由于资源已被删除，服务器返回 404。

尽管客户端收到的状态代码不同，但单个 DELETE 请求产生的效果与对同一 URI 的多个 DELETE 请求产生的效果相同。

最后，如果在客户端能够读取服务器响应之前发生通信故障，则可以自动重复使用幂等方法的请求。客户端知道重复请求将具有相同的预期效果，即使原始请求成功，尽管响应可能不同。

RFC 7231

让我们看看 RFC 7231 ，文档定义了 HTTP/1.1 协议(protocol)的语义和内容。请参阅下面的引用(重点是我的)。

HTTP 方法可以安全:

4.2.1. Safe Methods

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. [...]

This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. [...]

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. [...]

和/或幂等:

4.2.2. Idempotent Methods

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. [...]

Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request. [...]

总而言之，HTTP 方法被分类为 following :

+---------+------+------------+
| Method  | Safe | Idempotent |
+---------+------+------------+
| CONNECT | no   | no         |
| DELETE  | no   | yes        |
| GET     | yes  | yes        |
| HEAD    | yes  | yes        |
| OPTIONS | yes  | yes        |
| POST    | no   | no         |
| PUT     | no   | yes        |
| TRACE   | yes  | yes        |
+---------+------+------------+  

RFC 5789

RFC 5789定义 PATCH方法，既不安全也不幂等。但是，为了防止碰撞，PATCH可以以幂等的方式发出请求，如下所述:

A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. Clients using this kind of patch application SHOULD use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource. For example, the client can use a strong ETag in an If-Match header on the PATCH request.