一 原理區(qū)別
一般在瀏覽器中輸入網(wǎng)址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認(rèn)為GET提交
Http定義了與服務(wù)器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE
URL全稱是資源描述符，我們可以這樣認(rèn)為：一個URL地址，它用于描述一個網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對應(yīng)著對這個資源的查 ，改 ，增 ，刪 4個操作。到這里，大家應(yīng)該有個大概的了解了，GET一般用于獲取/查詢 資源信息，而POST一般用于更新 資源信息(個人認(rèn)為這是GET和POST的本質(zhì)區(qū)別，也是協(xié)議設(shè)計(jì)者的本意，其它區(qū)別都是具體表現(xiàn)形式的差異 )。
根據(jù)HTTP規(guī)范，GET用于信息獲取，而且應(yīng)該是安全的和冪等的 。
1.所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET請求一般不應(yīng)產(chǎn)生副作用。就是說，它僅僅是獲取資源信息，就像數(shù)據(jù)庫查詢一樣，不會修改，增加數(shù)據(jù)，不會影響資源的狀態(tài)。
* 注意：這里安全的含義僅僅是指是非修改信息。
2.冪等的意味著對同一URL的多個請求應(yīng)該返回同樣的結(jié)果。這里我再解釋一下冪等 這個概念：
冪等 （idempotent、idempotence）是一個數(shù)學(xué)或計(jì)算機(jī)學(xué)概念，常見于抽象代數(shù)中。
冪等有以下幾種定義：
對于單目運(yùn)算，如果一個運(yùn)算對于在范圍內(nèi)的所有的一個數(shù)多次進(jìn)行該運(yùn)算所得的結(jié)果和進(jìn)行一次該運(yùn)算所得的結(jié)果是一樣的，那么我們就稱該運(yùn)算是冪等的。比如絕對值運(yùn)算就是一個例子，在實(shí)數(shù)集中，有abs(a) = abs(abs(a)) 。
對于雙目運(yùn)算，則要求當(dāng)參與運(yùn)算的兩個值是等值的情況下，如果滿足運(yùn)算結(jié)果與參與運(yùn)算的兩個值相等，則稱該運(yùn)算冪等，如求兩個數(shù)的最大值的函數(shù)，有在在實(shí)數(shù)集中冪等，即max(x,x) = x 。
看完上述解釋后，應(yīng)該可以理解GET冪等的含義了。
但在實(shí)際應(yīng)用中，以上2條規(guī)定并沒有這么嚴(yán)格。引用別人文章的例子：比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。從根本上說，如果目標(biāo)是當(dāng)用戶打開一個鏈接時(shí)，他可以確信從自身的角度來看沒有改變資源即可。
根據(jù)HTTP規(guī)范，POST表示可能修改變服務(wù)器上的資源的請求 。繼續(xù)引用上面的例子：還是新聞以網(wǎng)站為例，讀者對新聞發(fā)表自己的評論應(yīng)該通過POST實(shí)現(xiàn)，因?yàn)樵谠u論提交后站點(diǎn)的資源已經(jīng)不同了，或者說資源被修改了。
上面大概說了一下HTTP規(guī)范中，GET和POST的一些原理性的問題。但在實(shí)際的做的時(shí)候，很多人卻沒有按照HTTP規(guī)范去做，導(dǎo)致這個問題的原因有很多，比如說：
1.很多人貪方便，更新資源時(shí)用了GET，因?yàn)橛肞OST必須要到FORM（表單），這樣會麻煩一點(diǎn)。
2.對資源的增，刪，改，查操作，其實(shí)都可以通過GET/POST完成，不需要用到PUT和DELETE。
3.另外一個是，早期的但是Web MVC框架設(shè)計(jì)者們并沒有有意識地將URL當(dāng)作抽象的資源來看待和設(shè)計(jì) 。還有一個較為嚴(yán)重的問題是傳統(tǒng)的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。
* 簡單解釋一下MVC：MVC本來是存在于Desktop程序中的，M是指數(shù)據(jù)模型，V是指用戶界面，C則是控制器。使用MVC的目的是將M和V的實(shí)現(xiàn)代碼分離，從而使同一個程序可以使用不同的表現(xiàn)形式。
以上3點(diǎn)典型地描述了老一套的風(fēng)格（沒有嚴(yán)格遵守HTTP規(guī)范），隨著架構(gòu)的發(fā)展，現(xiàn)在出現(xiàn)REST(Representational State Transfer)，一套支持HTTP規(guī)范的新風(fēng)格，這里不多說了，可以參考《RESTful Web Services》。
二 表現(xiàn)形式區(qū)別
搞清了兩者的原理區(qū)別，我們再來看一下他們實(shí)際應(yīng)用中的區(qū)別：
為了理解兩者在傳輸過程中的不同，我們先看一下HTTP協(xié)議的格式：
HTTP請求：
<request line>
<headers>
<blank line>
<request-body>]
在HTTP請求中，第一行必須是一個請求行（request line），用來說明請求類型、要訪問的資源以及使用的HTTP版本。緊接著是一個首部（header）小節(jié)，用來說明服務(wù)器要使用的附加信息。在首部之后是一個空行，再此之后可以添加任意的其他數(shù)據(jù)[稱之為主體（body）]。
GET與POST方法實(shí)例：
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
（----此處空一行----）
name=Professional%20Ajax&publisher=Wiley
有了以上對HTTP請求的了解和示例，我們再來看兩種提交方式的區(qū)別：
（1）GET提交，請求的數(shù)據(jù)會附在URL之后（就是把數(shù)據(jù)放置在HTTP協(xié)議頭中），以?分割URL和傳輸數(shù)據(jù)，多個參數(shù)用&連接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送，如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進(jìn)制表示的ASCII。
POST提交：把提交的數(shù)據(jù)放置在是HTTP包的包體中。上文示例中紅色字體標(biāo)明的就是實(shí)際的傳輸數(shù)據(jù)
因此，GET提交的數(shù)據(jù)會在地址欄中顯示出來，而POST提交，地址欄不會改變
(2)傳輸數(shù)據(jù)的大小：首先聲明：HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進(jìn)行限制。
而在實(shí)際開發(fā)中存在的限制主要有：
GET:特定瀏覽器和服務(wù)器對URL長度有限制，例如IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持。
因此對于GET提交時(shí)，傳輸數(shù)據(jù)就會受到URL長度的限制。
POST:由于不是通過URL傳值，理論上數(shù)據(jù)不受限。但實(shí)際各個WEB服務(wù)器會規(guī)定對post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。
(3)安全性：
.POST的安全性要比GET的安全性高。注意：這里所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的Security的含義，比如：通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)?1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號和密碼了，除此之外，使用GET提交數(shù)據(jù)還可能會造成Cross-site request forgery攻擊
（4）Http get,post,soap協(xié)議都是在http上運(yùn)行的
1）get：請求參數(shù)是作為一個key/value對的序列（查詢字符串）附加到URL上的
查詢字符串的長度受到web瀏覽器和web服務(wù)器的限制（如IE最多支持2048個字符），不適合傳輸大型數(shù)據(jù)集同時(shí)，它很不安全
2）post：請求參數(shù)是在http標(biāo)題的一個不同部分（名為entity body）傳輸?shù)模@一部分用來傳輸表單信息，因此必須將Content-type設(shè)置為:application/x-www-form-urlencoded。post設(shè)計(jì)用來支持web窗體上的用戶字段，其參數(shù)也是作為key/value對傳輸。
但是：它不支持復(fù)雜數(shù)據(jù)類型，因?yàn)閜ost沒有定義傳輸數(shù)據(jù)結(jié)構(gòu)的語義和規(guī)則。
3）soap：是http post的一個專用版本，遵循一種特殊的xml消息格式
Content-type設(shè)置為: text/xml 任何數(shù)據(jù)都可以xml化
三 HTTP響應(yīng)
1．HTTP響應(yīng)格式：
<status line>
<headers>
<blank line>
[<response-body>]
在響應(yīng)中唯一真正的區(qū)別在于第一行中用狀態(tài)信息代替了請求信息。狀態(tài)行（status line）通過提供一個狀態(tài)碼來說明所請求的資源情況。
HTTP響應(yīng)實(shí)例：
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
＜html＞
＜head＞
＜title＞W(wǎng)rox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞
2．最常用的狀態(tài)碼有：
◆200 (OK): 找到了該資源，并且一切正常。
◆304 (NOT MODIFIED): 該資源在上次請求之后沒有任何修改。這通常用于瀏覽器的緩存機(jī)制。
◆401 (UNAUTHORIZED): 客戶端無權(quán)訪問該資源。這通常會使得瀏覽器要求用戶輸入用戶名和密碼，以登錄到服務(wù)器。
◆403 (FORBIDDEN): 客戶端未能獲得授權(quán)。這通常是在401之后輸入了不正確的用戶名或密碼。
◆404 (NOT FOUND): 在指定的位置不存在所申請的資源。
四 完整示例：
例子：
HTTP GET
發(fā)送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com
回復(fù)
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
HTTP POST
發(fā)送
POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
UserID=string&PWD=string&OrderConfirmation=string
回復(fù)
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
SOAP 1.2
發(fā)送
POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>
回復(fù)
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
</soap12:Envelope>
出處：http://blog.csdn.net/gideal_wang/archive/2009/07/02/4316691.aspx