前言

昨天的文章介紹到了 HTTP/1.1 所定義的請求方法 ，今天就來講一下如何定義哪些方法是安全/不安全的，以及為什麼要做出這些區別吧！

上圖引用自MDN，對於請求方法有做了一個清楚的分類。

Safe method 是如何定義？

以下是 RFC 9110 中的定義：

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

當使用者端在使用安全方法時，不應該會導致伺服器端狀態的任何變更，也就是說安全方法本質上應該是唯讀的。但是這裡所定義的「安全」並不包含由請求所引發的副作用，使用者端的請求並不涵蓋這些額外的行為，因此依然會被視為安全的方法。舉例來說，大多數伺服器在完成回應後，通常會記錄請求資訊以便存取日誌，即使所使用的方法不同，這種操作仍可能導致伺服器失敗（例如，日誌存儲已滿）。

為什麼要區分方法是否安全？

• 為了讓自動化工具（例如網路爬蟲）能正常運作：網路爬蟲常用於網路搜尋引擎（ex. Google）建立網路索引，爬蟲會系統化地訪問網站上的各個頁面，分析內容，並將結果儲存在資料庫中，供搜尋引擎使用者進行搜尋，而網路搜尋引擎也藉此持續更新其索引。因為使用安全方法時並不會影響到伺服器的資料狀態，使用爬蟲時透過安全方法就可以避免造成任何改變，可以順利取得所需資料。

• 快取效能優化：透過 GET 等安全方法對伺服器送出請求時，伺服器可以將請求的資料進行快取，以避免頻繁地向伺服器請求相同的資料，造成效能的浪費。但透過 POST 等不安全方法送出請求時，對於伺服器端的資料狀態會造成改變（ex. 新增一篇文章），因此每次使用不安全方法時都應該要將請求發送到伺服器進行處理，如果將這類的請求進行快取的話，會造成重複新增同一篇一樣的文章，造成伺服器端的資料錯誤。

• 避免使用者進行錯誤的操作：user agent（網頁瀏覽器、APP）應該要能夠區別安全或是不安全的方法，並且在使用者做出一些改變伺服器資料狀態的時候進行一些警告。
  例如：在使用者進行 DELETE 操作進行刪除時，跳出類似如下的提醒視窗，避免使用者在不知情的狀況下做出改變資料的操作
  

小結

今天講了一下關於安全方法的定義，以及為什麼做出這些區別，之後在設計 RESTful API 的時候也要注意在使用請求方法的時候要依照這個規範，避免使用 GET 這類的安全方法做出刪除或其他改變伺服器狀態的操作，以防止在使用者操作過程中產生意外或不預期的狀況，也能夠有效降低風險並提升系統的穩定性與安全性。

參考資料

RFC 9110
MDN