安全架构-HTTP协议幂等性

幂等性设计是架构师必须具备的技能之一，需要深入理解幂等性设计的相关原理和解决方法。

---

上一篇文章中介绍了api接口的幂等性，主要从业务逻辑处理的方面进行业务保障，做到实现幂等性。本文介绍HTTP协议本身在幂等性方面的设计。

---

前言

HTTP协议是当前rpc,分布式架构，微服务架构中应用最广泛的协议之一，对HTTP需要有深入的了解，后续也将编写HTTP协议知识相关的系列文章，本文只介绍HTTP协议幂等性方面的设计。

---

一、http幂等性

首先看http协议网关里介绍的幂等性。

9.1 Safe and Idempotent Methods
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

9.1.2 Idempotent Methods
Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.

A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).

官网地址：https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

二、http请求方式简述

1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
注意：
1）方法名称是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Mothod Not Allowed）；当服务器不认识或者不支持对应的请求方法时，应返回状态码501（Not Implemented）。
2）HTTP服务器至少应该实现GET和HEAD/POST方法，其他方法都是可选的，此外除上述方法，特定的HTTP服务器支持扩展自定义的方法。

三、HTTP 协议的幂等性

以我们常见的四种 HTTP method 为例，加深我们对幂等这个概念的理解。

GET
GET 操作是幂等的，原因是 GET 操作根本不会对服务器产生任何修改。有人可能会说我们访问 GET /last_news 可能每次拿到的结果都不一样，这里幂等的一致性指的是数据库的最终的存储结果，而不是调用方拿到的返回结果

PUT
PUT 方法通常是对已经存在的资源进行修改，也是幂等的。比如我们发起多个把 A 替换成 B 的请求，最终的结果还会是 B

DELETE
DELETE 方法也是幂等的，例如我们连续发起多个对 A 的删除请求，如果第一个成功的话，后面的请求都应返回资源找不到的错误

POST
POST 一般是指新增资源，不是幂等的。如果连续发起三个 A 资源的增加，最终的结果会是三个 A 资源，而不是一个

总结

HTTP协议在部分请求中考虑了幂等性，在POST请求中，如果需要幂等性处理，就需要结合前文中api接口幂等性设计来处理。

参考资料
https://www.cnblogs.com/weibanggang/p/9454581.html