1. Method

請求方法，表明客戶端希望服務器對資源執(zhí)行的動作；

1.1 GET

向服務器請求資源。

1.2 HEAD

和GET方法的行為類似，但服務器在響應中只返回首部，不會返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。
可以做到：

• 不獲取資源的情況下了解資源的情況(比如，判斷器類型)
• 通過查看響應中的狀態(tài)碼，看看某個對象是否存在；
• 通過查看首部，測試資源是否被修改了；

1.3 PUT

與GET從服務器讀取文件相反，PUT方法回向服務器寫入文件。有些發(fā)布系統(tǒng)允許用戶創(chuàng)建WEB頁面，并用PUT直接將其安裝到WEB服務器上；
PUT方法的語義就是讓服務器用請求的主體部分來創(chuàng)建一個由所請求的URL命令的新文檔，或者如果那個URL已經存在的話，就用這個主體來代替它；
因為PUT允許用戶對內容進行修改，所以很多WEB服務器都要求在執(zhí)行PUT之前，用密碼登錄。

1.4 POST

向服務器發(fā)送要處理的數(shù)據；
一般服務器通常提供一個表單，客戶端填入數(shù)據后點擊提交(提交是數(shù)據都會放在請求報文的實體部分當中)，然后由服務器將其發(fā)送到它要去的地方（比如，送到一個服務器的網關程序中，然后由這個程序對其進行處理）；

1.5 TRACE

客戶端發(fā)起一個請求時，這個請求可能要穿過防火墻、代理、網關或其他一些應用程序。每個中間節(jié)點都可能會修改原始的HTTP請求。TRACE方法允許客戶端在最終將請求發(fā)給服務器時，看看它變成了什么樣子；
TRACE請求會在目的服務器發(fā)起一個“環(huán)回”針對。行程最后一站的服務器會彈出一條TRACE響應，并在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看所有中間HTTP應用程序組成的請求/響應鏈上，原始包文是否,以及如何被毀壞或修改過；

TRACE方法主要用于診斷；也就是說，用于驗證請求是否如愿的穿過了請求/響應鏈。它是一種很好的工具，可以用來查看代理和其他應用程序對用戶請求所產生的效果。
盡管TRACE可以很方便的用于診斷，但是它確實也有缺點，它假定中間應用程序對各種不同類型請求（GET、HEAD、POST等）的處理是相同的。很多HTTP應用程序會根據方法的不同做出不同的事情，比如，代理可能會將POST請求直接發(fā)給服務器，而將GET請求發(fā)送給另一個HTTP應用程序（比如WEB緩存）。TRACE并不提供區(qū)分這些方法的機制。通常，中間應用程序會自行決定對TRACE請求的處理方式。
TRACE請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應服務器收到的請求的精確副本。

1.6 DELETE

DELETE方法所做的事情就是請求服務器刪除請求URL所指定的資源。但是客戶端應用程序無法保證刪除操作一定會被執(zhí)行。因為HTTP規(guī)范允許服務器在不通知客戶端的情況下撤銷請求。

1.7 擴展方法

2 狀態(tài)返回碼

1xx：100-101, （額外）信息提示類的狀態(tài)碼；
2xx：200-206, 成功類的狀態(tài)碼；
3xx：300-305, 重定向類的狀態(tài)碼；沒有把請求的頁面響應給客戶端，而是重定向到其它地方，或是無需獲取此資源；
4xx：400-415, 錯誤類信息，客戶端的錯誤類的狀態(tài)碼；例如請求不存在的資源；
5xx：500-505, 錯誤類信息，服務器端錯誤類的狀態(tài)碼；例如服務器內部的問題，因為資源有語法錯誤運行部成功，無法響應，不是資源不存在；

2.1 200~299–成功狀態(tài)碼

200：OK
成功，請求的所有數(shù)據通過響應報文的entity-body部分發(fā)送；原因短語為OK；

201：Created
用于創(chuàng)建服務器對象的請求（比如，PUT）。響應實體主體部分中應該包含各種引用了已創(chuàng)建的資源的URL。Location首部包含的則是最具體的引用。服務器必須在發(fā)送這個狀態(tài)碼之前創(chuàng)建好對象；

202：Accepted
請求已被接受，但服務器還未對其執(zhí)行任何動作。不能保證服務器會完成這個請求；這只是意味著接受請求時，他看起來是有效的。服務器應該在實體的主體部分包含對請求狀態(tài)的描述，或許還應該有對請求完成時間的估計（或者包含一個指針，指向可以獲取此信息的位置）；

203：Non-Authoritative Information
實體首部包含的信息不是來自于源端服務器，而是來自資源的一份副本。如果中間節(jié)點上有一份資源副本，但無法或者沒有對它所發(fā)送的與資源有關的原信息（首部）進行驗證，就會出現(xiàn)這種情況；
這種響應嗎并不是非用不可的；如果實體首部來自源端服務器，相應為200狀態(tài)的應用程序就可以將其作為一種可選項使用；

204：No Content
響應報文中包含若干首部和一個狀態(tài)行，但沒有實體的主體部分。主要用于在瀏覽器不轉為顯示新文檔的情況下，對其進行更新（比如刷新一個表單頁面）；

205：Rest Content
另一個主要用于瀏覽器的代碼。負責告知瀏覽器清除當前頁面中的所有HTML表單元素；

206：Partial Content
成功執(zhí)行了一個部分或Range（范圍）請求。客戶端可以通過一些特殊的首部來獲取部分或某個范圍內的文檔–這個狀態(tài)碼就說明范文請求成功了；
206相應中必須包含Content-Range、Date以及ETag或Content-Location首部；

2.2 300~399–重定向狀態(tài)碼

可以通過某些重定向狀態(tài)碼對瀏覽器本地緩存的資源副本與遠端服務器上的資源進行驗證。比如：用來查看本地的副本是否仍為最新的，或者遠端服務器上的資源是否被修改過；
下圖是客戶端發(fā)送了一個特殊的if-Modified-Since首部，說明會讀取1997年10月之后修改過的文檔。因為這個日期之后，此文檔并未修改過，因此，服務器回送了一個304狀態(tài)碼，而不是文檔的內容；

300：Multiple Choices
客戶端請求一個實際指向多個資源的URL時就會返回這個狀態(tài)碼，比如服務器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表；這樣用戶就可以選擇他希望使用的那一項了。

301：Move Permanently
請求的URL指向的資源已經被刪除（移動到其它位置）是永久重定向，資源被永久刪除；但在響應報文中通過首部Location指明了資源現(xiàn)在所處的新位置；原因短語為Moved Permanently；

302：Found
與301相似，但在響應報文中通過Location指明資源現(xiàn)在所處臨時新位置，資源不是永久刪除，是臨時重定向; 原因短語為Found；

303：See Other
告知客戶端應該用另一個URL來獲取資源。新的URL位于響應報文的Location首部。其主要目的是允許POST請求的響應將客戶端定向到某個資源上去；

304：Not Modified
客戶端發(fā)出了條件式請求，但服務器上的資源未曾發(fā)生改變，則通過通過此響應狀態(tài)碼通知客戶端（帶有這個狀態(tài)碼的響應不應該包含實體的主體部分），客戶端可繼續(xù)使用本地網頁緩存；原因短語為Not Modified；

305：Use Proxy
用來說明必須通過一個代理來訪問資源；代理的位置有Location首部給出。
很重要的一點是，客戶端只是對某個特定資源來解析這條響應的；而不是對所有請求，甚至所有具有相同資源的服務器都通過這個代理進行；如果客戶端錯誤的讓代理介入了某個請求，可能會引發(fā)破壞性的行為，而且會造成安全漏洞；

306：未使用

307：Temporary Redirect
與301代碼類似；但客戶端應該使用Location首部給出URL來臨時定位資源。將來的請求還使用老的URL；

注意：
302、303、307狀態(tài)碼之間存在一些交叉。這些狀態(tài)碼的用法有細微的區(qū)別，大部分區(qū)別都源于HTTP/1.0和HTTP/1.1應用程序對這些狀態(tài)碼處理方式的不同。
當HTTP/1.0客戶端發(fā)起一個POST請求，并在響應中收到302重定向狀態(tài)碼時，它會接受Location首部的重定向URL，并向那個URL發(fā)起一個GET請求（而不會向原始請求中那樣發(fā)起POST請求）。
HTTP/1.0服務器希望HTTP/1.0客戶端這么做—如果HTTP/1.0服務器收到來自HTTP/1.0客戶端的POST請求之后發(fā)送了302狀態(tài)碼，服務器就期望客戶端能夠接受重定向URL，并向重定向的URL發(fā)送一個GET請求；

問題出在HTTP/1.1。HTTP/1.1規(guī)范您使用了303狀態(tài)碼來實現(xiàn)同樣的行為（服務器發(fā)送303狀態(tài)碼來重定向客戶端的POST請求，在它后面跟上一個GET請求）。
為避開這個問題，HTTP/1.1規(guī)范指出，對于HTTP/1.1客戶端，用307狀態(tài)碼取代302狀態(tài)碼來進行臨時重定向。這樣服務器就可以將302狀態(tài)碼保留起來，為HTTP/1.0客戶端使用。
這樣一來，服務器要選擇適當?shù)闹囟ㄏ驙顟B(tài)碼放入重定向響應中發(fā)送，就需要查看客戶端的HTTP版本了。

2.3 400~499–客戶端錯誤狀態(tài)碼

400：Bad Request
告知客戶端它發(fā)送了一個錯誤的請求；

401：Unauthorized
與適當?shù)氖撞恳煌祷?，在這些首部中要求客戶端在訪問資源之前，需要進行認證（如基于basic認證時就是401）。

402：Payment Required
保留

403：Forbidden
用于說明請求被服務器拒絕了。如果服務器想說明為什么拒絕請求，可以在包含請求實體的主體部分來對原因進行描述。但這個狀態(tài)碼通常是在服務器不想說明拒絕原因的時候使用的；

404：Not Found
用于說明服務器無法找到所請求的URL。通常會包含一個實體，以便客戶端應用程序顯示給用戶看；

405：Methord Not Allowed
發(fā)起的請求中帶有所請求的URL不支持的方法時，使用此狀態(tài)嗎。應該在響應中包含Allow首部，已告知客戶端對所請求資源可以使用哪些方法。

406：Not Acceptable
客???端可以指定參數(shù)來說明它們愿意接受什么類型的實體。服務器沒有與客戶端可接受的URL相匹配的資源時，使用此代碼。通常，服務器會包含一些首部，以便客戶端弄清楚為什么請求無法滿足。

407：Porxy Authentication Required
與401狀態(tài)碼類似，但用于要求對資源進行認證的代理服務器；

408：Request Timeout
如果客戶端完成請求所花的時間太長，服務器可以回送此狀態(tài)碼，并關閉連接。超時時長隨著服務器的不同有所不同，但通常對所有的合法請求來說，都是夠長的；

409：Conflict
用于說明請求可能在資源上引發(fā)的一些沖突。服務器擔心請求會引發(fā)沖突時，可以發(fā)送此狀態(tài)碼。響應中應該包含描述沖突的主體；

410：Gone
與404類似，只是服務器曾經擁有過此資源。主要用于WEB站點的維護，這樣服務器的管理員就可以在資源被移除的情況下通知客戶端了；

412：Precondition Failed
客戶端發(fā)起了條件請求，且其中一個條件失敗了的時候使用?？蛻舳税薊xpect首部時就是條件請求。

413：Request Entity Too Large
客戶端發(fā)送的實體主體部分比服務器能夠或希望處理的要大時，使用此狀態(tài)；

414：Request URI Too Long
客戶端所發(fā)送的請求中請求的URL比服務器能夠或者希望處理的要長時，使用此狀態(tài)碼；

415：Unsupported Media Type
服務器無法理解或無法支持客戶端所發(fā)實體的內容類型時，使用此狀態(tài)碼；

416：Requested Range Not Satisfiable
請求報文所請求的是指定資源的某個范圍，而此范圍無效或無法滿足時，使用此狀態(tài)碼；

417：Expectation Failed
請求的Expect請求首部包含了一個期望，但服務器無法滿足此期望時，使用此狀態(tài)碼。
如果代理或其他中間應用程序有確切證據說明源端服務器會為其請求產生一個失敗的期望，就可以發(fā)送這個響應狀態(tài)碼

2.4 500~599–服務器錯誤狀態(tài)碼

500：Internal Server Error
服務器內部錯誤。

501：Not Implemented
客戶端發(fā)起的請求超出了服務器的能力范圍（比如，使用了服務器不支持到的請求方法）。

502：Bad Gateway
作為代理或網關使用的服務器從請求相應鏈的下一跳鏈路上收到了一條偽相應（比如，它無法連接到其父網關）。

503：Service Unavailable
用來說明服務器現(xiàn)在無法為請求提供服務，但撿來可以。如果服務器知道什么時候資源會變?yōu)榭捎玫?，可用在響應中包含一個Retry-After首部。

504：Gateway Timout
與狀態(tài)碼408類似，只是這里的響應來自一個網關或代理，他們在等待另一個服務器對其請求的進行響應時超時了。

505：HTTP Version Not Supported
服務器收到了請求，是它無法或不愿支持的協(xié)議版本時，使用此狀態(tài)碼（有些服務器應用程序會選擇不支持協(xié)議的早期版本）。