什么样的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 请求不应该用来创建或者修改资源了。。。
