HTTP請求方式

一、 GET 

獲取被請求URI（Request-URI）指定的信息（以實體的格式）

請求URI設計到 一個數據生成過程，這個過程生成的數據應該被做爲實體在相應中返回而不是過程的源文本，除非源文本剛好是過程的輸出。

若是請求消息包含if-modified-since，if-unmodified-siince,if-match,if-none-match 或者if-range頭域，GET的語義將變成條件conditionall GET,

一個條件GET方法會請求知足條件頭域的實體。

條件GET方法的目的是爲了減小沒必要要的網絡使用，這經過容許利用緩存裏仍保鮮的實體而不用屢次請求或傳輸客戶端已經擁有的實體來實現。

若是請求方法包含一個Range頭域，那麼GET方法就變成部分GET（partial GET）方法。

一個部分GET會請求實體的一部分，部分GET方法的目的是爲了減小沒必要要的網絡使用，能夠容許客戶端從服務器獲取實體部分數據，而不須要獲取客戶端本地已經擁有的實體部分。

GET請求的響應是能夠緩存的（cacheable）若是此響應應知足HTTP緩存的要求，關於GET請求用於表單時安全考慮。

 

二、HEAD

與GET方法一致，除了服務器不能在相應裏返回消息主題，HEAD請求相應裏HTTP頭域裏的元信息（元信息就是頭域信息）應該和GET請求響應裏的元信息一致。

此方法被用來獲取請求實體的元信息而不須要傳輸實體主體（entity-body）此方法常常被用來測試超文本鏈接的有效性，可訪問性，和最近的改變。

HEAD請求的相應是能夠緩存的，響應裏的信息能夠被緩存用於更新之前那個資源對應緩存的實體。若是出現一個新的域值指明緩存的實體和當前源 服務器上德實體有什麼不一樣（可能由於Content-length,content-md5,etag,last-modified值的改變），那麼緩存cache必須認爲緩存項是過期的stale。

 

三、POST

用於請求源服務器接受請求中實體做爲請求資源的一個新的從屬物

功能：

已存在的資源的註釋；

發佈消息給一個佈告板，新聞組，郵件列表，類似的文章組；

提供一個數據塊，如提交一個表單給一個數據處理過程；

經過追加操做來擴展數據庫；

POST方法的實現功能是由服務器決定的，而且常常依賴於請求URI（Request-URI），POST提交的實體是請求URI的從屬物，好像一個文件從屬於一個目錄，一篇文章從屬於一個新聞組，或者一條記錄從屬於一個數據庫。

POST方法執行的動做可能不會對請求URI所指的資源起做用。

這種狀況下，200成功或者204沒有內容將是適合的相應狀態，這依賴於相應是否包含一個描述結果的實體。

若是資源被源服務器建立，響應應該是201created，而且包含一個實體，此實體描述了請求的狀態，引用了這個新資源和一個location頭域。

相應不可緩存，除非響應裏有合適的cache-control或者expires頭域，然而303（其餘）響應能被用戶代理利用去得到能夠緩存的響應。

必須遵循消息傳送的要求。

 

四、PUT

請求服務器把請求裏的實體存儲在請求URI(REQUEST-URI)標識下，

PUT

 

PUT方法請求服務器去把請求裏的實體存儲在請求URI（Request-URI）標識下。若是請求
URI（Request-URI）指定的的資源已經在源服務器上存在，那麼此請求裏的實體應該被看成
是源服務器關於此URI所指定資源實體的最新修改版本。若是請求URI（Request-URI）指定
的資源不存在，而且此URI被用戶代理定義爲一個新資源，那麼源服務器就應該根據請求裏的
實體建立一個此URI所標識下的資源。若是一個新的資源被建立了，源服務器必須能向用戶代
理（user agent） 發送201（已建立）響應。若是已存在的資源被改變了，那麼源服務器應該
發送200（Ok）或者204（無內容）響應。若是資源不能根據請求URI建立或者改變，一個合
適的錯誤響應應該給出以反應問題的性質。實體的接收者不能忽略任何它不理解和不能實現的
Content-*（如：Content-Range）頭域，而且必須返回501（沒有被實現）響應。
若是請求穿過一個緩存（cache），而且此請求URI（Request-URI）指示了一個或多個當前
緩存的實體，那麼這些實體應該被看做是舊的。PUT方法的響應是不可緩存的。
POST方法和PUT方法請求最根本的區別是請求URI（Request-URI）的含義不一樣。POST請
求裏的URI 指示一個能處理請求實體的資源（譯註：此資源多是一段程序，如jsp 裏的
servlet） 。此資源多是一個數據接收過程，一個網關（gateway，譯註：網關和代理的區別
是：網關能夠進行協議轉換，而代理不能，只是起代理的做用，好比緩存服務器其實就是一個
代理），或者一個單獨接收註釋的實體。對比而言，PUT方法請求裏的URI標識請求裏封裝的
實體一一用戶代理知道URI 意指什麼，而且服務器不能把此請求應用於其它資源
（resource）。若是服務器指望請求被應用於一個不一樣的URI，那麼它必須發送301（永久移
動）響應；用戶代理能夠本身決定是否重定向請求。
一個單獨的資源可能會被許多不一樣的URI指定。如：一篇文章可能會有一個URI指定當前版本，
而這個URI區別於這篇文章其它特殊版本的URI。這種狀況下，對一個通用URI的PUT請求可
能會致使其資源的其它URI請求被源服務器重定義。
HTTP/1.1沒有定義PUT方法對源服務器的狀態影響。
PUT請求必須遵循8.2節中的消息傳送的要求。
除非特別指出，PUT方法請求裏的實體頭域應該被用於資源的建立或修改。

 

DELETE（刪除）

 

DELETE方法請求源服務器刪除請求URI指定的資源。此方法可能會在源服務器上被人爲的幹
涉（或經過其餘方法）。客戶端不能保證此操做能被執行，即便源服務器返回成功狀態碼。然而，
服務器不該該指明成功除非它打算刪除資源或把此資源移到一個不可訪問的位置。
若是響應裏包含描述成功的實體，響應應該是200（OK）；若是DELETE動做尚未執行，
應該以202（已接受）響應；若是DELETE請求方法已經執行但響應不包含實體，那麼應該以
204（無內容）響應。
若是請求穿過緩存，而且請求URI（Request-URI）指定了一個或多個緩存當前實體，那麼這
些緩存項應該被認爲是舊的。DELETE方法的響應是不能被緩存的。

 

TRACE

 

TRACE方法被用於激發一個遠程的，應用層的請求消息迴路（譯註：TRACE方法讓客戶端測
試到服務器的網絡通路，迴路的意思如發送一個請返回一個響應，這就是一個請求響應迴路，）。

最後的接收者也許是源服務器，也許是接收到包含Max-Forwards頭域值爲0請求的代理
或網關。TRACE請求不能包含一個實體。
TRACE方法容許客戶端去了解數據被請求鏈的另外一端接收的狀況，而且利用那些數據信息去
測試或診斷。Via頭域值（見14.45）有特殊的用途，由於它能夠做爲請求鏈的跟蹤信息。利用
Max-Forwards頭域容許客戶端限制請求鏈的長度，這是很是有用的，由於能夠利用此去測試代
理鏈在無限循環裏轉發消息。
若是請求是有效的，響應應該在實體主體裏包含整個請求消息，而且響應應該包含一個
Content-Type頭域值爲」message/http」的頭域。此方法的響應不能被緩存。

 

CONNECT（鏈接）

 

HTTP1.1 協議規範保留了CONNECT方法，此方法是爲了能用於能動態切換到隧道的代理