使用ASP.NET Core 3.x 构建 RESTful API - 4.3 HTTP 方法的安全性和幂等性

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