GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT
HTTP Method的歷史：
- HTTP 0.9 這個版本只有GET方法
- HTTP 1.0 這個版本有GET HEAD POST這三個方法
- HTTP 1.1 這個版本是當(dāng)前版本，包含GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT這8個方法
我們要點(diǎn)餐，我們必須先知道菜單是甚麼（get），
我們會向服務(wù)生點(diǎn)餐（post），
我們想要取消剛才點(diǎn)的餐點(diǎn)（delete），
我們想要重新點(diǎn)一次（put），
我們想要加點(diǎn)甜點(diǎn)和飲料（patch）。
GET
GET方法意思是獲取被請求URI（Request-URI）指定的信息（以實(shí)體的格式）。如果請求URI涉及到一個數(shù)據(jù)生成過程，那么這個生成的數(shù)據(jù)應(yīng)該被作為實(shí)體在響應(yīng)中返回，但這并不是過程的資源文本，除非資源文本恰好是過程的輸出（譯注：URI指示的資源是動態(tài)生成的）。
如果請求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match,，If-None-Match,或者 If-Range頭域,，GET的語義將變成“條件（conditionall） GET”。一個條件GET方法會請求滿足條件頭域的實(shí)體。條件GET方法的目的是為了減少不必要的網(wǎng)絡(luò)使用，這通過利用緩存的實(shí)體的更新，從而不用多次請求或傳輸客戶已經(jīng)擁有的數(shù)據(jù)。
如果請求方法包含一個Range頭域，那么GET方法就變成“部分Get”方法。一個部分GET會請求實(shí)體的一部分，這在14.35節(jié)里描述了。 部分GET方法的目的是為了減少不必要的網(wǎng)絡(luò)使用，這通過允許獲取部分實(shí)體，從而不需要傳輸客戶端已經(jīng)擁有的數(shù)據(jù)。
GET請求的響應(yīng)是可緩存的（cacheable）
HEAD
HEAD方法和GET方法一致，除了服務(wù)器不能在響應(yīng)里返回消息主體。HEAD請求響應(yīng)里HTTP頭域里的元信息應(yīng)該和GET請求響應(yīng)里的元信息一致。此方法被用來獲取請求實(shí)體的元信息而不需要傳輸實(shí)體主體（entity-body）。此方法經(jīng)常被用來測試超文本鏈接的有效性，可訪問性，和最近的改變。.
HEAD請求的響應(yīng)是可緩存的，因?yàn)轫憫?yīng)里的信息可能被用于更新以前的那個資源的緩存實(shí)體.。如果出現(xiàn)一個新的域值指明了緩存實(shí)體和當(dāng)前源服務(wù)器上實(shí)體的不同（可能因?yàn)镃ontent-Length，Content-MD5，ETag或Last-Modified值的改變），那么緩存（cache）必須認(rèn)為此緩存項(xiàng)是過時的（stale）。
POST
POST 方法被用于請求源服務(wù)器接受請求中的實(shí)體作為請求資源的一個新的從屬物。POST被設(shè)計(jì)涵蓋下面的功能。
-已存在的資源的注釋；
-發(fā)布消息給一個布告板，新聞組，郵件列表，或者相似的文章組。
-提供一個數(shù)據(jù)塊，如提交一個表單給一個數(shù)據(jù)處理過程。
-通過追加操作來擴(kuò)展數(shù)據(jù)庫。
POST方法的實(shí)際功能是由服務(wù)器決定的，并且經(jīng)常依賴于請求URI（Request-URI）。POST提交的實(shí)體是請求URI的從屬物，就好像一個文件從屬于一個目錄，一篇新聞文章從屬于一個新聞組，或者一條記錄從屬于一個數(shù)據(jù)庫。
POST方法執(zhí)行的動作可能不會對請求URI所指的資源起作用。在這種情況下，200（成功）或者204（沒有內(nèi)容）將是適合的響應(yīng)狀態(tài)，這依賴于響應(yīng)是否包含一個描述結(jié)果的實(shí)體。
如果資源被源服務(wù)器創(chuàng)建，響應(yīng)應(yīng)該是201（Created）并且包含一個實(shí)體，此實(shí)體描述了請求的狀態(tài)并且此實(shí)體引用了一個新資源和一個Location頭域（見14.30節(jié)）。
POST方法的響應(yīng)是可緩存的。除非響應(yīng)里有Cache-Control或者Expires頭域指示其響應(yīng)不可緩存。然而，303（見其他）響應(yīng)能被利用去指導(dǎo)用戶代理（agent）去獲得可緩存的響應(yīng)。
POST 請求必須遵循8.2節(jié)里指明的消息傳輸需求。
參見15.1.3節(jié)關(guān)于安全性的考慮.
PUT
PUT方法請求服務(wù)器去把請求里的實(shí)體存儲在請求URI（Request-URI）標(biāo)識下。如果請求URI（Request-URI）指定的的資源已經(jīng)在源服務(wù)器上存在，那么此請求里的實(shí)體應(yīng)該被當(dāng)作是源服務(wù)器此URI所指定資源實(shí)體的修改版本。如果請求URI（Request-URI）指定的資源不存在，并且此URI被用戶代理（user agent，譯注：用戶代理可認(rèn)為是客戶瀏覽器）定義為一個新資源，那么源服務(wù)器就應(yīng)該根據(jù)請求里的實(shí)體創(chuàng)建一個此URI所標(biāo)識下的資源。如果一個新的資源被創(chuàng)建了，源服務(wù)器必須能向用戶代理（user agent） 發(fā)送201（已創(chuàng)建）響應(yīng)。如果已存在的資源被改變了，那么源服務(wù)器應(yīng)該發(fā)送200（Ok）或者204（無內(nèi)容）響應(yīng)。如果資源不能根據(jù)請求URI創(chuàng)建或者改變，一個合適的錯誤響應(yīng)應(yīng)該給出以反應(yīng)問題的性質(zhì)。實(shí)體的接收者不能忽略任何它不理解的Content-*（如：Content-Range）頭域，并且必須返回501（沒有被實(shí)現(xiàn)）響應(yīng)。
如果請求穿過一個緩存（cache），并且此請求URI（Request-URI）指示了一個或多個當(dāng)前緩存的實(shí)體，那么這些實(shí)體應(yīng)該被看作是舊的。PUT方法的響應(yīng)不應(yīng)該被緩存。
POST方法和PUT方法請求最根本的區(qū)別是請求URI（Request-URI）的含義不同。POST請求里的URI指示一個能處理請求實(shí)體的資源（譯注：此資源可能是一段程序，如jsp里的servlet） 。此資源可能是一個數(shù)據(jù)接收過程，一個網(wǎng)關(guān)（gateway，譯注：網(wǎng)關(guān)和代理服務(wù)器的區(qū)別是：網(wǎng)關(guān)可以進(jìn)行協(xié)議轉(zhuǎn)換，而代理服務(wù)器不能，只是起代理的作用，比如緩存服務(wù)器其實(shí)就是一個代理服務(wù)器），或者一個單獨(dú)接收注釋的實(shí)體。而PUT方法請求里有一個實(shí)體一一用戶代理知道URI意指什么，并且服務(wù)器不能把此請求應(yīng)用于其他URI指定的資源。如果服務(wù)器期望請求被應(yīng)用于一個不同的URI，那么它必須發(fā)送301（永久移動了）響應(yīng)；用戶代理可以自己決定是否重定向請求。
一個獨(dú)立的資源可能會被許多不同的URI指定。如：一篇文章可能會有一個URI指定當(dāng)前版本，此URI區(qū)別于其文章其他特殊版本的URI。這種情況下，一個通用URI的PUT請求可能會導(dǎo)致其資源的其他URI被源服務(wù)器定義。
HTTP/1.1沒有定義PUT方法對源服務(wù)器的狀態(tài)影響。
PUT請求必須遵循8.2節(jié)中的消息傳輸要求。
除非特別指出，PUT方法請求里的實(shí)體頭域應(yīng)該被用于資源的創(chuàng)建或修改。
DELETE
DELETE方法請求源服務(wù)器刪除請求URI指定的資源。此方法可能會在源服務(wù)器上被人為的干涉（或其他方法）。客戶端不能保證此操作能被執(zhí)行，即使源服務(wù)器返回成功狀態(tài)碼。然而，服務(wù)器不應(yīng)該指明成功除非它打算刪除資源或把此資源移到一個不可訪問的位置。
如果響應(yīng)里包含描述成功的實(shí)體，響應(yīng)應(yīng)該是200（Ok）；如果DELETE動作沒有通過，應(yīng)該以202（已接受）響應(yīng)；如果DELETE方法請求已經(jīng)通過了，但響應(yīng)不包含實(shí)體，那么應(yīng)該以204（無內(nèi)容）響應(yīng)。
如果請求穿過緩存，并且請求URI（Request-URI）指定一個或多個緩存當(dāng)前實(shí)體，那么這些緩存項(xiàng)應(yīng)該被認(rèn)為是舊的。DELETE方法的響應(yīng)是不能被緩存的。
