- 銜山的博客 - http://fengchangjian.com -
HTTP方法的安全性和冪等性
Posted By 銜山 On 2012 年 05 月 26 日 @ 下午 5:43 In 計算機網絡 | No Comments
Http協議規定了不同方法的安全特性和冪等特性，作為服務提供者的服務器必需為客戶端提供這些特性。安全性，僅指該方法的多次調用不會產生副作用，不涉及傳統意義上的“安全”，這里的副作用是指資源狀態。即，安全的方法不會修改資源狀態，盡管多次調用的返回值可能不一樣(被其他非安全方法修改過)。冪等性，是指該方法多次調用返回的效果(形式)一致，客戶端可以重復調用並且期望同樣的結果。冪等的含義類似於編程語言中的setter方法[1]，一次調用和多次調用產生的效果是一致的，都是對一個變量進行賦值。安全性和冪等性含義有些接近，容易搞混。
HTTP方法的安全性和冪等性見下表：
| 方法名 | 安全性 | 冪等性 |
|---|---|---|
| GET | 是 | 是 |
| HEAD | 是 | 是 |
| OPTIONS | 是 | 是 |
| DELETE | 否 | 是 |
| PUT | 否 | 是 |
| POST | 否 | 否 |
可以認為安全的方法都是只讀的方法(GET, HEAD, OPTIONS)，不會改變資源狀態，顯然，這三個方法也是冪等的。
DELETE方法的語義表示刪除服務器上的一個資源，第一次刪除成功后該資源就不存在了，資源狀態改變了，所以DELETE方法不具備安全特性。然而HTTP協議規定DELETE方法是冪等的，每次刪除該資源都要返回狀態碼200 OK，服務器端要實現冪等的DELETE方法，必須記錄所有已刪除資源的元數據(Metadata),否則，第二次刪除后返回的響應碼就會類似404 Not Found了。
PUT和POST方法語義中都有修改資源狀態的意思，因此都不是安全的。但是PUT方法是冪等的，POST方法不是冪等的，這么設計的理由是：
HTTP協議規定，POST方法修改資源狀態時，URL指示的是該資源的父級資源，待修改資源的ID信息在請求體中攜帶[2]。而PUT方法修改資源狀態時，URL直接指示待修改資源[2]。因此，同樣是創建資源，重復提交POST請求可能產生兩個不同的資源，而重復提交PUT請求只會對其URL中指定的資源起作用，也就是只會創建一個資源。
References:
[1] Subbu Allamaraju著, 丁雪豐等譯. RESTful Web Services Cookbook中文版. 電子工業出版社.
[2] Hypertext Transfer Protocol — HTTP/1.1. Method Definitions: POST [1]
[3] Hypertext Transfer Protocol — HTTP/1.1. Method Definitions: PUT [2]
–EOF–
Article printed from 銜山的博客: http://fengchangjian.com
URL to article: http://fengchangjian.com/?p=1653
URLs in this post:
[1] Method Definitions: POST: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
[2] Method Definitions: PUT: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6