使用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 請求不該該用來建立或者修改資源了。。。