ASP.NET Core 3.x RESTful API学习记录–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/rfc7231https://tools.ietf.org/html/rfc5789)。它们不仅仅是纯理论,它们应该在不同的业务场景中合理的使用。 

现在我们都应该知道了为什么 GET 请求不应该用来创建或者修改资源了。。。 

知识来源草根专栏 感谢杨旭大佬

相关文章