HTTP POST GET 本質區分詳解
1 原理區分
1般在閱讀器中輸入網址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或POST，默許為GET提交
Http定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE
URL全稱是資源描寫符，我們可以這樣認 為：1個URL地址，它用于描寫1個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查 ，改 ，增 ，刪 4個操作。到這里，大家應當有個大概的了解了，GET1般用于獲得/查詢 資源信息，而POST1般用于更新 資源信息(個人認為這是GET和POST的本質區分，也是協議設計者的本意，其它區分都是具體表現情勢的差異 )。
　　根據HTTP規范，GET用于信息獲得，而且應當是安全的和冪等的 。
　　1.所謂安全的意味著該操作用于獲得信息而非修改信息。換句話說，GET要求1般不應產生副作用。就是說，它僅僅是獲得資源信息，就像數據庫查詢1樣，不會修改，增加數據，不會影響資源的狀態。
　　* 注意：這里安全的含義僅僅是指是非修改信息。
　　2.冪等的意味著對同1URL的多個要求應當返回一樣的結果。這里我再解釋1下冪等 這個概念：
　　冪等 （idempotent、idempotence）是1個數學或計算機學概念，常見于抽象代數中。
　　冪等有以下幾種定義：
　　對單目運算，如果1個運算對在范圍內的所有的1個數屢次進行該運算所得的結果和進行1次該運算所得的結果是1樣的，那末我們就稱該運算是冪等的。比如絕對值運算就是1個例子，在實數集中，有abs(a) =abs(abs(a)) 。
　　對雙目運算，則要求當參與運算的兩個值是等值的情況下，如果滿足運算結果與參與運算的兩個值相等，則稱該運算冪等，如求兩個數的最大值的函數，有在在實數集中冪等，即max(x,x) = x 。
看完上述解釋后，應當可以理解GET冪等的含義了。
　　但在實際利用中，以上2條規定并沒有這么嚴格。援用他人文章的例子：比如，新聞站點的頭版不斷更新。雖然第2次要求會返回不同的1批新聞，該操 作依然被認為是安全的和冪等的，由于它總是返回當前的新聞。從根本上說，如果目標是當用戶打開1個鏈接時，他可以確信從本身的角度來看沒有改變資源便可。
　　根據HTTP規范，POST表示可能修改變服務器上的資源的要求 。繼續援用上面的例子：還是新聞以網站為例，讀者對新聞發表自己的評論應當通過POST實現，由于在評論提交后站點的資源已不同了，或說資源被修改了。
　　上面大概說了1下HTTP規范中，GET和POST的1些原理性的問題。但在實際的做的時候，很多人卻沒有依照HTTP規范去做，致使這個問題的緣由有很多，比如說：
　　1.很多人貪方便，更新資源時用了GET，由于用POST必須要到FORM（表單），這樣會麻煩1點。
　　2.對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE。
　　3.另外1個是，初期的但是Web MVC框架設計者們并沒有成心識地將URL當作抽象的資源來看待和設計 。還有1個較為嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。
　　* 簡單解釋1下MVC：MVC本來是存在于Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實現代碼分離，從而使同1個程序可使用不同的表現情勢。
　　以上3點典型地描寫了老1套的風格（沒有嚴格遵照HTTP規范），隨著架構的發展，現在出現REST(Representational State Transfer)，1套支持HTTP規范的新風格，這里不多說了，可以參考《RESTful Web Services》。
2 表現情勢區分
弄清了二者的原理區分，我們再來看1下他們實際利用中的區分：
為了理解二者在傳輸進程中的不同，我們先看1下HTTP協議的格式：
HTTP要求：



]
在HTTP要求中，第1行必須是1個要求行（request line），用來講明要求類型、要訪問的資源和使用的HTTP版本。緊接著是1個首部（header）小節，用來講明服務器要使用的附加信息。在首部以后是1個空行，再此以后可以添加任意的其他數據[稱之為主體（body）]。
GET與POST方法實例：
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive

POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（―-此處空1行―-）
name=Professional%20Ajax&publisher=Wiley

有了以上對HTTP要求的了解和示例，我們再來看兩種提交方式的區分：
（1）GET提交，要求的數據會附在URL以后（就是把數據放置在要求行（request line）中），以?分割URL和傳輸數據，多個參數用&連接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。Url的編碼格式采取的是ASCII碼，而不是Unicode，這也就是說你不能在Url中包括任何非ASCII字符，所有非ASCII字符均需要編碼再傳輸，關于Url編碼可參考：http://kb.cnblogs.com/page/133765/。
　　POST提交：把提交的數據放置在是HTTP包的包體中。上文示例中紅色字體標明的就是實際的傳輸數據
因此，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上，由于(1)登錄頁面有可能被閱讀器緩存， (2)其他人查看閱讀器的歷史紀錄，那末他人就能夠拿到你的賬號和密碼了，除此以外，使用GET提交數據還可能會造成Cross-site request forgery攻擊
（4）Http get,post,soap協議都是在http上運行的
1）get：要求參數是作為1個key/value對的序列（查詢字符串）附加到URL上的
查詢字符串的長度遭到web閱讀器和web服務器的限制（如IE最多支持2048個字符），不合適傳輸大型數據集同時，它很不安全
2）post：要求參數是在http標題的1個不同部份（名為entity body）傳輸的，這1部份用來傳輸表單信息，因此必須將Content-type設置為:application/x-www-form-urlencoded。post設計用來支持web窗體上的用戶字段，其參數也是作為key/value對傳輸。
但是：它不支持復雜數據類型，由于post沒有定義傳輸數據結構的語義和規則。
3）soap：是http post的1個專用版本，遵守1種特殊的xml消息格式
Content-type設置為: text/xml 任何數據都可以xml化

3 HTTP響應
1．HTTP響應格式：



[]

在響應中唯1真實的區分在于第1行中用狀態信息代替了要求信息。狀態行（status line）通過提供1個狀態碼來講明所要求的資源情況。

HTTP響應實例：

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO⑻859⑴
Content-Length: 122
＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈