[RESTful]HTTP狀態碼

　　HTTP狀態碼是一個依附於HTTP響應的3位數字，它是協議語義的一部分，能在最基本的層面上讓客戶端知道服務器在嘗試處理請求的時候發生了什麼事情。HTTP規範總共定義了41一個響應碼，本文將對全部的狀態碼進行介紹。

　　RFC2616

1、狀態碼家族

　　HTTP狀態碼的第一位數字是代表請求進展狀況的一個很是通用的指示。HTTP規範使用1~5做爲首數字分別定義了5個狀態碼家族。

　　1xx：Information

　　僅在HTTP客戶端與服務器之間進行協商時使用。

　　2xx：Successful

　　客戶端所要求的任意的狀態碼轉換已經發生。

　　3xx：Redirection

　　客戶端要求的狀態轉換沒有發生。可是若是客戶端願意發起一個稍有不一樣的HTTP請求，該請求應該會完成客戶端要求的行爲。

　　4xx：Client Error

　　因爲HTTP請求的問題，致使客戶端要求的狀態轉換沒有發生。該請求可能有缺陷、不合邏輯、自相矛盾或者該請求沒法被服務器接受。

　　5xx：Server Error

　　因爲服務器端的問題，致使客戶端要求的狀態轉換沒有發生。客戶端或許什麼都作不了，只能等待問題被修復。

2、最低限度的四個狀態碼(200 301 400 500)

　　200(OK)

　　一切都很是順利，實體消息體重的文檔(若是有)是某個資源的一份表述。

　　301(Moved Permanently)

　　當客戶端觸發了某個將資源從一個URL移動到另外一個URL的狀態轉換時將會發送該狀態碼。在移動後，向老的URL發送的請求將一樣會致使一個301狀態碼。

　　400（Bad Request）

　　客戶端存在問題。實體消息體中的文檔(若是有)是一段錯誤消息。但願客戶端能理解錯誤消息並使用它來修復問題。

　　500(Internal Server Error)

　　服務器端存在問題。實體消息體中的文檔是一段錯誤的消息。該錯誤消息可能幫不了什麼忙，由於客戶端不能修復服務器端的問題。

3、狀態碼列表

　　1xx：Information

　　100(Continue)

　　重要性：低到中等

　　這是應對HTTP look-before-you-leap(LBYL)請求的可能相應中的一種。該狀態碼指示客戶端應該從新發送它的初始請求，包括在首次請求中被省略了的(可能較大或較敏感)表述。客戶端不須要擔憂發送表述後又被拒絕的問題。應對LBYL請求的另外一個可能的相應是417(Expectation Failed)。

　　101(Switching Protocols)

　　重要性：很是低

　　客戶端只會在當請求中使用了Upgrade報頭來通知服務器它想要選擇使用排除HTTP以外的別的協議時纔會收到該響應碼。101狀態碼的意思是說「沒問題，如今我開始使用另一種協議跟你交談」。

 

　　2xx：Successful

　　200(OK)

　　重要性：很是高

　　這是客戶端大部分狀況下但願看到的狀態碼。它指示狀態轉換已經結束，而且在2xx系列中找不到更加具體且合適的狀態碼的時候可使用它。

　　201(Created)

　　重要性：高

　　當服務器基於客戶端的請求建立了新的資源後它會發送改狀態碼。

　　202(Accepted)

　　重要性：中等

　　客戶端的請求不能或者不會被實時地處理，而且將會在後續被處理。

　　203(Non-Authoritative Information)

　　重要性：很是低

　　該狀態碼與200相同，可是除此以外服務器還想讓客戶端了解一些並不是來自該服務器的相應報頭。這些報頭可能反映自客戶端的前一個請求，或者是從第三方組織得到的。

　　204(No Content)

　　重要性：高

　　該狀態碼一般在響應例如PUT請求這樣的非安全請求時被髮送，意思是服務器已經執行了狀態轉換，可是它拒絕發送回任何表述或狀態轉換的描述。服務器可能會在對應GET請求的響應中發送回204。這意味着該請求的資源存在，可是它擁有一個空的表述。相比於304(Not Modified)，204一般見於瀏覽器中的JavaScript應用。它讓服務器能夠告訴客戶端，客戶端的輸入已經被接受，可是該客戶端不該該修改任何的UI元素。

　　205(Requet Content)

　　重要性：低

　　該狀態相似於204，可是它暗示了客戶端應該重置數據來源的視圖或數據結構。若是你在你的Web瀏覽器中提交了一個HTML表單，並獲得了204的響應，那麼你的數據仍然還在表單裏，而你還能夠修改它們。可是若是你獲得一個205，這些表單字段將會重置爲它們的原始值。

　　206(Partial Conent)

　　重要性：對於支持partial GET 的API來講很是高，而對於其餘API則比較比較低。

　　該響應碼相似於200，可是它被指定做爲partial GET請求的響應：也就是說，該請求使用了Content-Range這一請求報頭。客戶端一般會發起一個局部請求來恢復一個被中斷的大型二進制表述的下載。

　　3xx：Redirection

　　300(Multiple Choices)

　　重要性：低

　　當被請求的資源具備多個表述時，服務器會在不知道客戶端想要哪個表述時發送該狀態碼。致使這樣的緣由要麼是由於客戶端沒有使用Accept-*報頭來指定表述，要麼是由於它所請求的表述並不存在。

　　在這種狀況下，服務器能夠挑選一個它偏好的表述，而後將它和200狀態碼一同發回。可是它也可能會決定發送300以及一組連接到不一樣表述的URI。

　　301(Moved Permanently)

　　重要性：中等

　　服務器知道客戶端嘗試訪問哪一個資源，可是客戶端並不關心它用於請求資源的URL。它但願客戶端能注意到新的URL並在未來的請求中使用新的URL。

　　你能夠再API改變了URL結構以後使用該狀態碼來保持老的URL的可用性，使其不被破壞。

　　302(Found)

　　重要性：重要，不推薦使用

　　該狀態碼即是大部分與重定向相關的困惑的最終來源。它的處理方式本應該像307那樣，而事實上，它在HTTP1.0中的名字是Moved Temporarily。不幸的是，在現實生活中，大部分客戶端是像處理303同樣來處理302的。與303的區別之處在於當客戶端在PUT、POST或者DELETE請求的響應中獲得302響應碼以後應該作些什麼。

　　爲了解決歧義，在HTTP1.0中，該響應碼已經被重命名爲Found，而同時建立了一個新的響應碼307.可是302響應碼仍然被普遍的使用着，而它是具備歧義的，因此建議應該經過303,307,308來取代302.

　　303(See Other)

　　重要性：高

　　請求已經被處理，可是服務器沒有發送響應文本，取而代之的是發送給客戶端一個響應文檔的URL。這多是一個靜態的狀態消息或者是某些更有意思的資源的URL。在後一種方式中，303的服務器在向客戶端發送了資源的表述以後卻不強制客戶端下載全部數據的一種方式。客戶端被預期使用的GET請求來訪問Location中提到的URL，可是這並非必須的。

　　303狀態碼是能夠用於對資源進行標準化的一種很好的方式。它科室使你的資源能經過不少URL被訪問到，可是每一個表述只有一個「真正的」URL。其餘全部的URL都是使用303來連接到表述的標準URL。

　　304(Not Modified)

　　重要性：高

　　該狀態碼與204類似，在啊該響應中，消息體必定是空的。可是204是當沒有消息體數據能夠發送時使用的，而304是本來有數據，但客戶端已經擁有了該數據時使用的，此時沒有必要從新發送數據。

　　該狀態碼是與有條件的HTTP請求同時使用的。若是客戶端發送了一個If-Modified-Since報頭以及值爲Sunday的日期值，而且表述子啊Sunday以後就沒有再發生過改變，此時304是很是適合的。使用200也是合適的，可是再次發送表述就會浪費帶寬，由於客戶端已經擁有該表述了。

　　305(Use Proxy)

　　重要性：低

　　該狀態碼用於告知客戶端應該重複它的請求，可是是經過一個HTTP代理而不是直接發向服務器。該狀態碼不多被使用，由於服務器不多會關心客戶端是否使用了特定代理。該狀態碼在基於代理的鏡像站點中會用得比較頻繁。

　　306(Unused)

　　重要性：無

　　306狀態碼從未被記錄到RFC中。它是互聯網草案"draft-cohen-http-305-306-responses"中做爲切換代理之用描述的，代理服務器發送該狀態碼來讓客戶端開始使用另外一個不一樣的代理。該互聯網草案在1996年就已通過時。

　　307(Temporary Redirect)

　　重要性：高

　　該請求還沒有被處理，由於請求的資源並不存在本URL內：它位於某個其餘的URL上。客戶端應該向另外一個URL從新提交請求。

　　當對應GET請求時，請求的惟一內容就是讓服務器發送一個表述，該狀態碼此時與303相同。一個典型的場景是當服務器想要將發起GET請求的客戶端傳送到一個鏡像站點時，307將是響應的很好選擇。可是對於POST、PUT和DELETE請求，服務器逾期將會在對應請求的響應中採起一些動做，這是該狀態碼與303顯著的區別。

　　對應POST、PUT或DELETE的303響應意味着操做已經成功，可是對應請求的本次響應中不會發送實體消息體。若是客戶端想要響應的實體消息體，它須要向另外一個URL發起GET請求。

　　對應POST、PUT或DELETE的307響應意味着服務器甚至還沒有嘗試執行操做。客戶端須要向Location報頭中的URL從新期繳整個請求。

　　308(Permanent Redirect)

　　重要性：中等

　　對應GET請求的308響應與301類似。可是對應非安全請求的308響應工做方式相似307：客戶端應該向Location報頭中給出的URL從新提交請求。不一樣之處在於客戶端應該在將來它想要發起的任何請求中繼續使用該新的URL。

　　4xx：Client-Side Error

　　400(Bad Request)

　　重要性：很是高

　　這是經過的客戶端錯誤狀態，當在其餘4xx錯誤碼中找不到更合適的選擇時能夠選擇該錯誤碼。一般在客戶端經過PUT或POST請求提交表述，而且表述的格式正確，可是表述自己卻沒有任何意義時，服務器會使用該狀態碼。

　　401(Unauthorized)

　　重要性：高

　　客戶端在沒有提供適當的身份認證憑證的時候向受保護的資源發送請求。它可能提供了錯誤的憑證或徹底沒有提供憑證。憑證可使用戶名和密碼。一個API key或者是一個認證的token——任何API資源質詢時所指望的內容。一般客戶端向URL發起請求會接收到一個401響應，這樣它就知道了該發送什麼類型的憑證並採用什麼樣的格式。事實上，HTTP Digest模式的認證便依賴這種行爲。

　　若是服務器並不想向未受權的用戶認可資源的存在，它能夠選擇撒謊併發送404來取代401.這樣的負做用是客戶端須要提早知道服務器指望對該資源進行什麼類型的認證。像HTTP Digest這樣的協議將沒法正常工做。

　　402(Payment Required)

　　重要性：無

　　除了它的名字以外，該狀態碼並無在HTTP標準中進行定義：它是「保留以備未來之用」的。這是由於目前尚未針對HTTP的小額支付系統。這就是說，若是可能出現HTTP的小額支付系統，那麼API將會在這些系統出現的地方首當其衝。若是你想經過HTTP請求向你的用戶收費，你和他們之間的關係將使得這一點成爲可能，而此時你將可使用該狀態碼。

　　可是已經存在大量經過請求進行收費的API，而我並不知道有任何這方面的API使用了該狀態碼。它將可能永遠保持「保留」狀態。

　　403(Forbidden)

　　重要性：中等

　　客戶端的請求格式正確，可是服務器並不想去執行它。不只僅是由於憑證不足：若是是這樣可使用401.這更像是資源容許在特定時間或來自特定IP段的請求進行訪問。403響應覺得着客戶端向其發起請求的資源真正存在。和401同樣，若是如武器甚至連這些信息也不想提供時，它能夠選擇撒謊併發送一個404取而代之。

　　404(Not Found)

　　重要性：高

　　404大概算是上最著名的HTTP狀態碼了。404指示了服務器沒法將客戶端請求的URL映射到任何資源。咱們來將它與410進行對比，這樣會更加有幫助。請記住，404是任何用於掩蓋403或401的一個謊話。有可能資源是存在的，可是服務器並不想讓客戶端知道這一真相。

　　405(Method Not Allow)

　　重要性：中等

　　客戶端嘗試使用的某個HTTP方法對應的資源並不支持。舉個例子：一個只讀資源僅能夠支持GET和HEAD。而集和資源一般容許GET和POST，可是並不支持PUT或DELETE。

　　406(Not Acceptable)

　　重要性：中等

　　當客戶端對可接受的表述作了不少約束時(可能會使用Accept-*請求報頭)，服務器會在沒法發送任何表述時發送該響應碼。服務器也能夠選擇忽略客戶端的挑剔，簡單地發送響應碼200以及本身偏好的表述。

　　407(Proxy Authentication Required)

　　重要性：低

　　你只能從HTTP代理看到該狀態碼。它跟401很像，除了對應的問題再也不是你再使用API時沒有提供憑證，而是在使用代理時沒有提供憑據。跟401同樣，該問題多是由於客戶端沒有提供憑證，或者提供的憑證損壞或不足。

　　408(Request Timeout)

　　重要性：低

　　若是HTTP客戶端打開了一個與服務器之間的鏈接。可是從不發送請求(或者從不發送標識請求結束的空行)，服務器應該最終發送一個408響應碼來關閉這個鏈接。

　　409(Conflict)

　　重要性：很是高

　　客戶端嘗試在服務器上建立一個不可能或不一致的資源狀態。什麼是「不可能」 或 「不一致」取決於API的應用語義。一個基於集合API會容許客戶端DELETE一個空的集合，可是當客戶端嘗試DELETE一個還包含成員的集合時，將會發送409。

　　410(Gone)

　　重要性：中等

　　該響應碼很像404，可是它提供了略爲更多的信息。當服務器知道所請求的URL曾經指向某個資源，但目前已經再也不指向該資源時，就會發送該狀態碼。服務器並不知道該資源的任何新的URL；若是他知道它能夠發送301。

　　與301永久重定向相同的是，410響應碼暗示了客戶端應該從它當前的詞彙表裏面去除掉當前的URL，並中止向該URL繼續發送請求。與301不一樣的是，410沒有爲毀壞的URL提供代替：它指示提供不存在了。RFC2616建議爲「那些限時、增值的服務以及那些屬於某些再也不工做於該服務器站點的個體的資源」使用410響應碼。

(未完待續)

轉載請註明來源：http://www.cnblogs.com/caoming/p/4158662.html

參考資料：O'REILLY RESTful Web APIS