HTTP 方法中的幂等性是什么? [英] What is idempotency in HTTP methods?

问题描述

我已经阅读了 HTTP 文档，但我不明白什么是幂等性.有人可以帮忙吗?

解决方案

什么是 HTTP 方法中的幂等性?

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

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

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

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

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

RFC 7231

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

HTTP 方法可以安全:

<块引用>

4.2.1.安全方法

请求方法被认为是安全的"；如果它们定义的语义本质上是只读的；即，客户端不会请求，也不期望将安全方法应用于目标资源而导致源服务器上的任何状态更改.[...]

安全方法的这种定义不会阻止实现包含潜在有害的行为、并非完全只读的行为，或者在调用安全方法时会导致副作用的行为.然而，重要的是客户没有要求额外的行为并且不能为此负责.[...]

在本规范定义的请求方法中，GET、HEAD、OPTIONS 和 TRACE 方法被定义为安全的.[...]

和/或幂等:

<块引用>

4.2.2.幂等方法

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

与safe的定义一样，幂等性只适用于用户提出的请求；服务器可以自由地分别记录每个请求，保留修订控制历史记录，或为每个幂等请求实现其他非幂等副作用.[...]

总而言之，HTTP 方法分类为以下:

+---------+------+------------+|方法 |安全 |幂等 |+---------+------+------------+|连接 |没有|没有||删除 |没有|是 ||获取 |是 |是 ||头 |是 |是 ||选项 |是 |是 ||发布 |没有|没有||放 |没有|是 ||跟踪 |是 |是 |+---------+------+------------+

RFC 5789

RFC 5789 定义了 PATCH 方法，它既不安全也不幂等.但是，为了防止冲突，PATCH 请求可以以幂等的方式发布，如下所示:

<块引用>

PATCH 请求可以以幂等的方式发出，这也有助于防止同一资源上的两个 PATCH 请求之间的冲突导致不良结果类似的时间框架.来自多个 PATCH 请求的冲突可能比 PUT 冲突更危险，因为某些补丁格式需要从已知基点进行操作，否则它们会破坏资源.使用这种补丁应用程序的客户端应该使用条件请求，这样如果自客户端上次访问资源以来资源已更新，则请求将失败.例如，客户端可以在 PATCH 请求的 If-Match 标头中使用强 ETag.

I've read HTTP documentation, but I can't understand what is idempotency. Can someone help?

解决方案

What is idempotency in HTTP methods?

Idempotency is a property of HTTP 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. And it's worthwhile to mention that idempotency is about the effect produced on the state of the resource on the server and not about the response status code received by the client.

To illustrate this, consider the DELETE method, which is defined as idempotent. Now consider a client performs a DELETE request to delete a resource from the server. The server processes the request, the resource gets deleted and the server returns 204. Then the client repeats the same DELETE request and, as the resource has already been deleted, the server returns 404.

Despite the different status code received by the client, the effect produced by a single DELETE request is the same effect of multiple DELETE requests to the same URI.

Finally, requests with idempotent methods can be repeated automatically if a communication failure occurs before the client is able to read the server's response. The client knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might be different.

RFC 7231

Let's have a look at the RFC 7231, the document defines the semantics and the content of the HTTP/1.1 protocol. See the quotes below (highlights are mine).

HTTP methods can be safe:

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

And/or idempotent:

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

Summarizing, the HTTP methods are classified as 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

The RFC 5789 defines the PATCH method, which is neither safe nor idempotent. However, to prevent collisions, PATCH requests can be issued such a way as to be idempotent, as quoted below:

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.

这篇关于HTTP 方法中的幂等性是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！