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