1. 程式人生 > 其它 >http冪等性 post get put delete patch

http冪等性 post get put delete patch

HTTP的冪等性

HTTP協議本身是一種面向資源的應用層協議,但對HTTP協議的使用實際上存在著兩種不同的方式:一種是RESTful的,它把HTTP當成應用層協議,比較忠實地遵守了HTTP協議的各種規定;另一種是SOA的,它並沒有完全把HTTP當成應用層協議,而是把HTTP協議作為了傳輸層協議,然後在HTTP之上建立了自己的應用層協議。本文所討論的HTTP冪等性主要針對RESTful風格的,不過正如上一節所看到的那樣,冪等性並不屬於特定的協議,它是分散式系統的一種特性;所以,不論是SOA還是RESTful的Web API設計都應該考慮冪等性。下面將介紹HTTP GET、DELETE、PUT、POST四種主要方法的語義和冪等性。

HTTP GET方法用於獲取資源,不應有副作用,所以是冪等的。比如:GET http://www.bank.com/account/123456,不會改變資源的狀態,不論呼叫一次還是N次都沒有副作用。請注意,這裡強調的是一次和N次具有相同的副作用,而不是每次GET的結果相同。GET http://www.news.com/latest-news這個HTTP請求可能會每次得到不同的結果,但它本身並沒有產生任何副作用,因而是滿足冪等性的。

HTTP DELETE方法用於刪除資源,有副作用,但它應該滿足冪等性。比如:DELETE http://www.forum.com/article/4231,呼叫一次和N次對系統產生的副作用是相同的,即刪掉id為4231的帖子;因此,呼叫者可以多次呼叫或重新整理頁面而不必擔心引起錯誤。

比較容易混淆的是HTTP POST和PUT。POST和PUT的區別容易被簡單地誤認為“POST表示建立資源,PUT表示更新資源”;而實際上,二者均可用於建立資源,更為本質的差別是在冪等性方面。在HTTP規範中對POST和PUT是這樣定義的:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line …… If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

POST所對應的URI並非建立的資源本身,而是資源的接收者。比如:POST http://www.forum.com/articles的語義是在http://www.forum.com/articles下建立一篇帖子,HTTP響應中應包含帖子的建立狀態以及帖子的URI。兩次相同的POST請求會在伺服器端建立兩份資源,它們具有不同的URI;所以,POST方法不具備冪等性。而PUT所對應的URI是要建立或更新的資源本身。比如:PUT http://www.forum/articles/4231的語義是建立或更新ID為4231的帖子。對同一URI進行多次PUT的副作用和一次PUT是相同的;因此,PUT方法具有冪等性。

上面大概說了一下HTTP規範中GET和POST的一些原理性的問題。但在實際的做的時候,很多人卻沒有按照HTTP規範去做,導致這個問題的原因有很多,比如說:

1.很多人貪方便,更新資源時用了GET,因為用POST必須要到FORM(表單),這樣會麻煩一點。

2.對資源的增,刪,改,查操作,其實都可以通過GET/POST完成,不需要用到PUT和DELETE。

3.另外一個是,早期的Web MVC框架設計者們並沒有有意識地將URL當作抽象的資源來看待和設計,所以導致一個比較嚴重的問題是傳統的Web MVC框架基本上都只支援GET和POST兩種HTTP方法,而不支援PUT和DELETE方法。

  * 簡單解釋一下MVC:MVC本來是存在於Desktop程式中的,M是指資料模型,V是指使用者介面,C則是控制器。使用MVC的目的是將M和V的實現程式碼分離,從而使同一個程式可以使用不同的表現形式。

  以上3點典型地描述了老一套的風格(沒有嚴格遵守HTTP規範),隨著架構的發展,現在出現REST(Representational State Transfer),一套支援HTTP規範的新風格,這裡不多說了,可以參考《RESTful Web Services》。

說完原理性的問題,我們再從表面現像上面看看GET和POST的區別:

1.GET請求的資料會附在URL之後(就是把資料放置在HTTP協議頭中),以?分割URL和傳輸資料,引數之間以&相連,如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果資料是英文字母/數字,原樣傳送,如果是空格,轉換為+,如果是中文/其他字元,則直接把字串用BASE64加密,得出如:%E4%BD%A0%E5%A5%BD,其中%XX中的XX為該符號以16進製表示的ASCII。

POST把提交的資料則放置在是HTTP包的包體中。

2."GET方式提交的資料最多隻能是1024位元組,理論上POST沒有限制,可傳較大量的資料,IIS4中最大為80KB,IIS5中為100KB"??!

  以上這句是我從其他文章轉過來的,其實這樣說是錯誤的,不準確的:

(1).首先是"GET方式提交的資料最多隻能是1024位元組",因為GET是通過URL提交資料,那麼GET可提交的資料量就跟URL的長度有直接關係了。而實際上,URL不存在引數上限的問題,HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及伺服器對它的限制。IE對URL長度的限制是2083位元組(2K+35)。對於其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決於作業系統的支援。

  注意這是限制是整個URL長度,而不僅僅是你的引數值資料長度。[見參考資料5]

(2).理論上講,POST是沒有大小限制的,HTTP協議規範也沒有進行大小限制,說“POST資料量存在80K/100K的大小限制”是不準確的,POST資料是沒有限制的,起限制作用的是伺服器的處理程式的處理能力。

  對於ASP程式,Request物件處理每個表單域時存在100K的資料長度限制。但如果使用Request.BinaryRead則沒有這個限制。

  由這個延伸出去,對於IIS 6.0,微軟出於安全考慮,加大了限制。我們還需要注意:

1).IIS 6.0預設ASP POST資料量最大為200KB,每個表單域限制是100KB。
2).IIS 6.0預設上傳檔案的最大大小是4MB。
3).IIS 6.0預設最大請求頭是16KB。
IIS 6.0之前沒有這些限制。[見參考資料5]

  所以上面的80K,100K可能只是預設值而已(注:關於IIS4和IIS5的引數,我還沒有確認),但肯定是可以自己設定的。由於每個版本的IIS對這些引數的預設值都不一樣,具體請參考相關的IIS配置文件。

3.在ASP中,服務端獲取GET請求引數用Request.QueryString,獲取POST請求引數用Request.Form。在JSP中,用request.getParameter(\"XXXX\")來獲取,雖然jsp中也有request.getQueryString()方法,但使用起來比較麻煩,比如:傳一個test.jsp?name=hyddd&password=hyddd,用request.getQueryString()得到的是:name=hyddd&password=hyddd。在PHP中,可以用$_GET和$_POST分別獲取GET和POST中的資料,而$_REQUEST則可以獲取GET和POST兩種請求中的資料。值得注意的是,JSP中使用request和PHP中使用$_REQUEST都會有隱患,這個下次再寫個文章總結。

4.POST的安全性要比GET的安全性高。注意:這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作資料修改,而這裡安全的含義是真正的Security的含義,比如:通過GET提交資料,使用者名稱和密碼將明文出現在URL上,因為(1)登入頁面有可能被瀏覽器快取,(2)其他人檢視瀏覽器的歷史紀錄,那麼別人就可以拿到你的賬號和密碼了,除此之外,使用GET提交資料還可能會造成Cross-site request forgery攻擊。

  總結一下,Get是向伺服器發索取資料的一種請求,而Post是向伺服器提交資料的一種請求,在FORM(表單)中,Method預設為"GET",實質上,GET和POST只是傳送機制不同,並不是一個取一個發!