一 原理差別
一般在浏覽器中輸入網址通路資源都是通過GET方式;在FORM送出中,可以通過Method指定送出方式為GET或者POST,預設為GET送出
Http定義了與伺服器互動的不同方法,最基本的方法有4種,分别是GET,POST,PUT,DELETE
URL全稱是資源描述符,我們可以這樣認 為:一個URL位址,它用于描述一個網絡上的資源,而HTTP中的GET,POST,PUT,DELETE就對應着對這個資源的查 ,改 ,增 ,删 4個操作。到這裡,大家應該有個大概的了解了,GET一般用于擷取/查詢 資源資訊,而POST一般用于更新 資源資訊(個人認為這是GET和POST的本質差別,也是協定設計者的本意,其它差別都是具體表現形式的差異 )。
根據HTTP規範,GET用于資訊擷取,而且應該是安全的和幂等的 。
- 所謂安全的意味着該操作用于擷取資訊而非修改資訊。換句話說,GET請求一般不應産生副作用。就是說,它僅僅是擷取資源資訊,就像資料庫查詢一樣,不會修改,增加資料,不會影響資源的狀态。
注意:這裡安全的含義僅僅是指是非修改資訊。
- 幂等的意味着對同一URL的多個請求應該傳回同樣的結果。這裡我再解釋一下幂等 這個概念:
幂等 (idempotent、idempotence)是一個數學或計算機學概念,常見于抽象代數中。 幂等有以下幾種定義:
對于單目運算,如果一個運算對于在範圍内的所有的一個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的,那麼我們就稱該運算是幂等的。比如絕對值運算就是一個例子,在實數集中,有abs(a) =abs(abs(a)) 。 對于雙目運算,則要求當參與運算的兩個值是等值的情況下,如果滿足運算結果與參與運算的兩個值相等,則稱該運算幂等,如求兩個數的最大值的函數,有在在實數集中幂等,即max(x,x) = x 。
看完上述解釋後,應該可以了解GET幂等的含義了。
但在實際應用中,以上2條規定并沒有這麼嚴格。引用别人文章的例子:比如,新聞站點的頭版不斷更新。雖然第二次請求會傳回不同的一批新聞,該操 作仍然被認為是安全的和幂等的,因為它總是傳回目前的新聞。從根本上說,如果目标是當使用者打開一個連結時,他可以确信從自身的角度來看沒有改變資源即可。
根據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協定的格式:
HTTP請求:
<request line>
<headers>
<blank line>
<request-body>]
在HTTP請求中,第一行必須是一個請求行(request line),用來說明請求類型、要通路的資源以及使用的HTTP版本。緊接着是一個首部(header)小節,用來說明伺服器要使用的附加資訊。在首部之後是一個空行,再此之後可以添加任意的其他資料[稱之為主體(body)]。
GET與POST方法執行個體:
GET
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
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請求的了解和示例,我們再來看兩種送出方式的差別:
- 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送出,位址欄不會改變
傳輸資料的大小
首先聲明:HTTP協定沒有對傳輸的資料大小進行限制,HTTP協定規範也沒有對URL長度進行限制。
而在實際開發中存在的限制主要有:
GET:特定浏覽器和伺服器對URL長度有限制,例如IE對URL長度的限制是2083位元組(2K+35)。對于其他浏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決于作業系統的支援。
是以對于GET送出時,傳輸資料就會受到URL長度的限制。
POST:由于不是通過URL傳值,理論上資料不受限。但實際各個WEB伺服器會規定對post送出資料大小進行限制,Apache、IIS6都有各自的配置。
安全性:
POST的安全性要比GET的安全性高。注意:這裡所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作資料修改,而這 裡安全的含義是真正的Security的含義,比如:通過GET送出資料,使用者名和密碼将明文出現在URL上,因為(1)登入頁面有可能被浏覽器緩存, (2)其他人檢視浏覽器的曆史紀錄,那麼别人就可以拿到你的賬号和密碼了,除此之外,使用GET送出資料還可能會造成Cross-site request forgery攻擊
Http get,post,soap協定都是在http上運作的
- get:請求參數是作為一個key/value對的序列(查詢字元串)附加到URL上的查詢字元串的長度受到web浏覽器和web伺服器的限制(如IE最多支援2048個字元),不适合傳輸大型資料集同時,它很不安全
- post:請求參數是在http标題的一個不同部分(名為entity body)傳輸的,這一部分用來傳輸表單資訊,是以必須将Content-type設定為:application/x-www-form-urlencoded。post設計用來支援web窗體上的使用者字段,其參數也是作為key/value對傳輸。但是:它不支援複雜資料類型,因為post沒有定義傳輸資料結構的語義和規則。
- soap:是http post的一個專用版本,遵循一種特殊的xml消息格式. Content-type設定為: text/xml 任何資料都可以xml化
三 HTTP響應
HTTP響應格式:
<status line>
<headers>
<blank line>
[<response-body>]
在響應中唯一真正的差別在于第一行中用狀态資訊代替了請求資訊。狀态行(status line)通過提供一個狀态碼來說明所請求的資源情況。
HTTP響應執行個體:
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>Wrox Homepage</title>
</head>
<body>
<!-- body goes here -->
</body>
</html>
最常用的狀态碼有:
- 200 (OK): 找到了該資源,并且一切正常。
- 304 (NOT MODIFIED): 該資源在上次請求之後沒有任何修改。這通常用于浏覽器的緩存機制。
- 401 (UNAUTHORIZED): 用戶端無權通路該資源。這通常會使得浏覽器要求使用者輸入使用者名和密碼,以登入到伺服器。
- 403 (FORBIDDEN): 用戶端未能獲得授權。這通常是在401之後輸入了不正确的使用者名或密碼。
- 404 (NOT FOUND): 在指定的位置不存在所申請的資源。
四 完整示例:
例子:
HTTP GET
發送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com
回複
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
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
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
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>
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>