GET 和 POST

參考文章1:http://www.cnblogs.com/nankezhishi/archive/2012/06/09/getandpost.html
參考文章2:http://blog.csdn.net/clsdata/article/details/5519837/
參考文章3:http://www.cnblogs.com/ldp615/archive/2012/07/27/http-get-post.html


HTTP Request Methods

GET 和 POST都屬於HTTP Request Methods。HTTP Request Methods 不只是 GET 和 POST,完整列表如下:

  • GET
  • POST
  • PUT
  • DELETE
  • HEAD
  • OPTIONS
  • TRACE
  • CONNECT
  • PATCH

REST 使用前四個:GET、POST、PUT、DELETE。因些這四個也是經常被一塊提及的。
URL全稱是資源描述符,可以這樣認爲,一個URL地址,它用於描述一個網絡上的資源,而HTTP中的GET,POST,PUT,DELETE就對應着對這個資源的查 ,改 ,增 ,刪 4個操作。GET一般用於獲取/查詢 資源信息,而POST一般用於更新 資源信息。

HTTP規範

GET

根據HTTP規範,GET用於信息獲取,而且應該是安全的和冪等的 。

  • 所謂安全的意味着該操作用於獲取信息而非修改信息。換句話說,GET請求一般不應產生副作用。就是說,它僅僅是獲取資源信息,就像數據庫查詢一樣,不會修改,增加數據,不會影響資源的狀態。
    注意:這裏安全的含義僅僅是指是非修改信息。

  • 冪等的意味着對同一URL的多個請求應該返回同樣的結果。
    冪等 (idempotent、idempotence)是一個數學或計算機學概念,常見於抽象代數中。
    冪等有以下幾種定義:

    • 對於單目運算,如果一個運算對於在範圍內的所有的一個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的,那麼我們就稱該運算是冪等的。比如絕對值運算就是一個例子,在實數集中,有abs(a) = abs(abs(a)) 。
    • 對於雙目運算,則要求當參與運算的兩個值是等值的情況下,如果滿足運算結果與參
      與運算的兩個值相等,則稱該運算冪等,如求兩個數的最大值的函數,有在在實數集中冪等,即max(x,x) = x 。

  但在實際應用中,以上2條規定並沒有這麼嚴格。引用別人文章的例子:比如,新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞,該操作仍然被認爲是安全的和冪等的,因爲它總是返回當前的新聞。從根本上說,如果目標是當用戶打開一個鏈接時,他可以確信從自身的角度來看沒有改變資源即可。

POST

根據HTTP規範,POST表示可能修改變服務器上的資源的請求 。繼續引用上面的例子:還是新聞以網站爲例,讀者對新聞發表自己的評論應該通過POST實現,因爲在評論提交後站點的資源已經不同了,或者說資源被修改了。

實際應用

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

  • 很多人貪方便,更新資源時用了GET,因爲用POST必須要到FORM(表單),這樣會麻煩一點。
  • 對資源的增,刪,改,查操作,其實都可以通過GET/POST完成,不需要用到PUT和DELETE。
  • 另外一個是,早期的但是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》。

表現形式

HTTP請求格式

<request-line>
<headers>
<blank line>
[<request-body>]

說明:第一行必須是一個請求行(request-line),用來說明請求類型,要訪問的資源以及所使用的HTTP版本。緊接着是一個首部(header)小節,用來說明服務器要使用的附加信息。之後是一個空行。再後面可以添加任意的其他數據[稱之爲主體(body)]。

GET 方法實例

GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
Connection: Keep-Alive

POST 方法實例

POST / HTTP/1.1
Host: www.wrox.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive----此處空一行----)
name=Professional%20Ajax&publisher=Wiley

區別

有了以上對HTTP請求的瞭解和示例,我們再來看兩種提交方式的區別:

(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包的包體中。上文示例中name=Professional%20Ajax&publisher=Wiley的就是實際的傳輸數據。
因此,GET提交的數據會在地址欄中顯示出來,而POST提交,地址欄不會改變

(2) 傳輸數據的大小

首先聲明,HTTP協議沒有對傳輸的數據大小進行限制,HTTP協議規範也沒有對URL長度進行限制。而在實際開發中存在的限制主要有:
GET:特定瀏覽器和服務器對URL長度有限制,例如IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決於操作系統的支持。
因此對於GET提交時,傳輸數據就會受到URL長度的限制。
POST:由於不是通過URL傳值,理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制,Apache、IIS6都有各自的配置。

(3) 安全性

POST的安全性要比GET的安全性高。注意:這裏所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數據修改,而這裏安全的含義是真正的Security的含義,比如:通過GET提交數據,用戶名和密碼將明文出現在URL上,因爲

  • 登錄頁面有可能被瀏覽器緩存
  • 其他人查看瀏覽器的歷史紀錄,那麼別人就可以拿到你的賬號和密碼了,除此之外,使用GET提交數據還可能會造成Cross-site request forgery攻擊。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章