HTTP狀態碼是一個依附於HTTP響應的3位數字，它是協議語義的一部分，能在最基本的層面上讓客戶端知道服務器在嘗試處理請求的時候發生了什么事情。HTTP規范總共定義了41一個響應碼，本文將對所有的狀態碼進行介紹。
一、狀態碼家族
HTTP狀態碼的第一位數字是表明請求進展情況的一個非常通用的指示。HTTP規范使用1~5作為首數字分別定義了5個狀態碼家族。
1xx：Information
僅在HTTP客戶端與服務器之間進行協商時使用。
2xx：Successful
客戶端所要求的任意的狀態碼轉換已經發生。
3xx：Redirection
客戶端要求的狀態轉換沒有發生。但是如果客戶端願意發起一個稍有不同的HTTP請求，該請求應該會完成客戶端要求的行為。
4xx：Client Error
由於HTTP請求的問題，導致客戶端要求的狀態轉換沒有發生。該請求可能有缺陷、不合邏輯、自相矛盾或者該請求無法被服務器接受。
5xx：Server Error
由於服務器端的問題，導致客戶端要求的狀態轉換沒有發生。客戶端或許什么都做不了，只能等待問題被修復。
二、最低限度的四個狀態碼(200 301 400 500)
200(OK)
一切都非常順利，實體消息體重的文檔(如果有)是某個資源的一份表述。
301(Moved Permanently)
當客戶端觸發了某個將資源從一個URL移動到另一個URL的狀態轉換時將會發送該狀態碼。在移動后，向老的URL發送的請求將同樣會導致一個301狀態碼。
400（Bad Request）
客戶端存在問題。實體消息體中的文檔(如果有)是一段錯誤消息。希望客戶端能理解錯誤消息並使用它來修復問題。
500(Internal Server Error)
服務器端存在問題。實體消息體中的文檔是一段錯誤的消息。該錯誤消息可能幫不了什么忙，因為客戶端不能修復服務器端的問題。
三、狀態碼列表
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響應碼。
(未完待續)