Http:Get、Post、Put、Delete、Head、Options詳解

1、概述

    Http定義了與服務器交互的不一樣方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，咱們能夠這樣認爲：一個URL地址，它用於描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應着對這個資源的查，改，增，刪4個操做。還有兩個則爲擴展型協議請求方法Head、Options。

2、請求方法含義

• Get：GET能夠說是最多見的了，它本質就是發送一個請求來取得服務器上的某一資源。資源經過一組HTTP頭和呈現據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。
• Head：HEAD和GET本質是同樣的，區別在於HEAD不含有呈現數據，而僅僅是HTTP頭信息。有的人可能以爲這個方法沒什麼用，其實不是這樣的。想象一個業務情景：欲判斷某個資源是否存在，咱們一般使用GET，但這裏用HEAD則意義更加明確。
• Post：向服務器提交數據。這個方法用途普遍，幾乎目前全部的提交操做都是靠這個完成。
• Put：這個方法比較少見。HTML表單也不支持這個。本質上來說， PUT和POST極爲類似，都是向服務器發送數據，但它們之間有一個重要區別，PUT一般指定了資源的存放位置，而POST則沒有，POST的數據存放位置由服務器本身決定。
• Delete：刪除某一個資源。基本上這個也不多見，不過仍是有一些地方好比amazon的S3雲服務裏面就用的這個方法來刪除資源。
• Options：這個方法頗有趣，但極少使用。它用於獲取當前URL所支持的方法。若請求成功，則它會在HTTP頭中包含一個名爲「Allow」的頭，值是所支持的方法，如「GET, POST」。

3、請求方法詳解

    1.Get描述

        根據HTTP規範，GET用於信息獲取，並且應該是安全的和冪等的，提交的數據最多隻能是1024字節。

• 所謂安全的意味着該操做用於獲取信息而非修改信息。換句話說，GET請求通常不該產生反作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢同樣，不會修改，增長數據，不會影響資源的狀態。這裏安全的含義僅僅是指是非修改信息。
• 冪等的意味着對同一URL的多個請求應該返回一樣的結果。這裏我再解釋一下冪等 這個概念

冪等（idempotent、idempotence）是一個數學或計算機學概念，常見於抽象代數中。
　　冪等有一下幾種定義：

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

    但在實際應用中以上2條規定並無這麼嚴格。 

    2.Post描述

    根據HTTP規範，POST表示可能修改變服務器上的資源的請求，理論上POST沒有限制，可傳較大量的數據，IIS4中最大爲80KB，IIS5中爲100KB。GET和POST的一些原理性的問題。但在實際的作的時候，不少人卻沒有按照HTTP規範去作，致使這個問題的緣由有不少，好比說：  

• 不少人貪方便，更新資源時用了GET，由於用POST必需要到FORM（表單），這樣會麻煩一點。  
• 對資源的增，刪，改，查操做，其實均可以經過GET/POST完成，不須要用到PUT和DELETE。  
• 另一個是，早期的可是Web MVC框架設計者們並無有意識地將URL看成抽象的資源來看待和設計 。還有一個較爲嚴重的問題是傳統的Web MVC框架基本上都只支持GET和POST兩種HTTP方法，而不支持PUT和DELETE方法。  

    以上3點典型地描述了老一套的風格（沒有嚴格遵照HTTP規範），隨着架構的發展，如今出現REST，它出來一套支持HTTP規範的新風格，能夠參考《RESTful Web Services》。 

4、表現形式

    1.Get

• Get請求

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1  
Host: api.efxnow.com

• Get響應

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>

    2.Post

• 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

• Post響應

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>

5、常見狀態碼

• 100 Continue：初始的請求已經接受，客戶應當繼續發送請求的其他部分
• 101 Switching Protocols：服務器將聽從客戶的請求轉換到另一種協議
• 200 OK：一切正常，對GET和POST請求的應答文檔跟在後面
• 201 Created：服務器已經建立了文檔，Location頭給出了它的URL。
• 202 Accepted：已經接受請求，但處理還沒有完成。
• 203 Non-Authoritative Information：文檔已經正常地返回，但一些應答頭可能不正確，由於使用的是文檔的拷貝
• 204 No Content：沒有新文檔，瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面，而Servlet能夠肯定用戶文檔足夠新，這個狀態代碼是頗有用的
• 205 Reset Content：沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容
• 206 Partial Content：客戶發送了一個帶有Range頭的GET請求，服務器完成了它
• 300 Multiple Choices：客戶請求的文檔能夠在多個位置找到，這些位置已經在返回的文檔內列出。若是服務器要提出優先選擇，則應該在Location應答頭指明。
• 301  Moved Permanently：客戶請求的文檔在其餘地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
• 302 Found：相似於301，但新的URL應該被視爲臨時性的替代，而不是永久性的。
• 303 See Other：相似於301/302，不一樣之處在於，若是原來的請求是POST，Location頭指定的重定向目標文檔應該經過GET提取
• 304 Not Modified：客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。
• 305 Use Proxy：客戶請求的文檔應該經過Location頭所指明的代理服務器提取
• 307 Temporary Redirect：和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即便原來的請求是 POST，即便它實際上只能在POST請求的應答是303時才能重定向。因爲這個緣由，HTTP 1.1新增了307，以便更加清除地區分幾個狀態代碼： 當出現303應答時，瀏覽器能夠跟隨重定向的GET和POST請求；若是是307應答，則瀏覽器只能跟隨對GET請求的重定向。
• 400 Bad Request：請求出現語法錯誤。
• 401 Unauthorized：客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示用戶名字/密碼對話框，而後在填寫合適的Authorization頭後再次發出請求。
• 403 Forbidden：資源不可用。
• 404 Not Found：沒法找到指定位置的資源
• 405 Method Not Allowed：請求方法（GET、POST、HEAD、Delete、PUT、TRACE等）對指定的資源不適用。
• 406 Not Acceptable：指定的資源已經找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容。
• 407 Proxy Authentication Required：相似於401，表示客戶必須先通過代理服務器的受權。
• 408 Request Timeout：在服務器許可的等待時間內，客戶一直沒有發出任何請求。客戶能夠在之後重複同一請求。
• 409 Conflict：一般和PUT請求有關。因爲請求和資源的當前狀態相沖突，所以請求不能成功。
• 410 Gone：所請求的文檔已經再也不可用，並且服務器不知道應該重定向到哪個地址。它和404的不一樣在於，返回407表示文檔永久地離開了指定的位置，而404表示因爲未知的緣由文檔不可用。
• 411 Length Required：服務器不能處理請求，除非客戶發送一個Content-Length頭。
• 412 Precondition Failed：請求頭中指定的一些前提條件失敗。
• 413 Request Entity Too Large：目標文檔的大小超過服務器當前願意處理的大小。若是服務器認爲本身可以稍後再處理該請求，則應該提供一個Retry-After頭。
• 414 Request URI Too Long：URI太長
• 416 Requested Range Not Satisfiable：服務器不能知足客戶在請求中指定的Range頭
• 500 Internal Server Error：服務器遇到了意料不到的狀況，不能完成客戶的請求
• 501 Not Implemented：服務器不支持實現請求所須要的功能。例如，客戶發出了一個服務器不支持的PUT請求
• 502 Bad Gateway：服務器做爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答
• 503 Service Unavailable：服務器因爲維護或者負載太重未能應答。例如，Servlet可能在數據庫鏈接池已滿的狀況下返回503，服務器返回503時能夠提供一個Retry-After頭
• 504 Gateway Timeout：由做爲代理或網關的服務器使用，表示不能及時地從遠程服務器得到應答
• 505 HTTP Version Not Supported：服務器不支持請求中所指明的HTTP版本。