什么样的 HTTP 方法是安全的?
如果一个方法不会改变资源的表述, 那么这个方法就被认为是安全的.
例如 HTTP GET 和 HTTP HEAD 就被认为是安全的, 但需要注意的是, 这并不意味着执行 GET 请求就不会引起其它的资源操作, 在表面之下, 你的服务层有可能会对其它相关的一些表的数据做出修改, 但是本资源的表述不应该被改变. 但即使相关的一些数据被修改了, 这也不是 API 消费者所请求的事.
什么样的 HTTP 方法是幂等的?
如果一个方法执行多次和执行一次的结果 (带来的副作用) 是一样的话, 那么这个方法就被认为是幂等的.
HTTP 方法的安全和幂等表:
其中:
GET 是安全的也是幂等的, 首先它不会改变资源的表述, 而且针对某个资源 (的 URI) 执行一次和执行多次 GET 的结果是一样的, 这里的结果是指它带来的副作用, 因为 GET 请求没有副作用, 所以执行一次和执行多次的副作用是一样的, 也就是都没有副作用.
而 OPTIONS 和 HEAD 的原理和 GET 是一样的.
POST 既不安全也不幂等, 首先它会改变资源的表述, 因为 POST 会创建资源, 而且如果执行多次 POST 的话, 多个资源会被创建.
DELETE 也是不安全的, 因为它会删除资源, 也就是修改了资源的表述. 但是 DELETE 却是幂等的, 因为对某个资源执行一次删除和执行多次删除的效果是一样的.
PUT(整体修改或叫整体替换), 它会修改资源所以不是安全的. 但是 PUT 却是幂等的, 对某个资源执行多次整体修改 (或者叫替换) 和执行一次的效果是一样的(当然请求 body 里面的参数每次也要一样).
PATCH(局部更新)既不是安全的也不是幂等的. 它会修改资源表述, 所以不是安全的. 但是为什么它和 PUT 不一样, PATCH 不是幂等的呢? 因为 PUT 其实是整体替换, 替换多次和一次的效果是一样的, 而 PATCH 是针对局部进行修改. 比如说公司这个资源有个集合属性叫做员工, 而某个 PATCH 请求会往公司的员工集合里添加一个员工, 那么执行一次 PATCH 就会添加一个员工, 而执行多次 PATCH 会增加多个员工, 通过这个例子可以看出, PATCH(局部更新)不是幂等的.
HTTP 方法的安全性和幂等性是 HTTP 标准文档中的一部分(https://tools.ietf.org/html/rfc7231,https://tools.ietf.org/html/rfc5789). 它们不仅仅是纯理论, 它们应该在不同的业务场景中合理的使用.
现在我们都应该知道了为什么 GET 请求不应该用来创建或者修改资源了...
来源: https://www.cnblogs.com/cgzl/p/12153505.html