HTTP/1.1協議中共定義了八種方法（有時也叫“動作”）來表明Request-URI指定的資源的不同操作方式。
OPTIONS 返回服務器針對特定資源所支持的HTTP請求方法。也可以利用向Web服務器發送'*'的請求來測試服務器的功能性。
HEAD 向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
GET 向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在web app.中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT 向指定資源位置上傳其最新內容。
DELETE 請求服務器刪除Request-URI所標識的資源。
TRACE 返回顯服務器收到的請求，主要用於測試或診斷。
CONNECT HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
詳述：
0，GET：GET可以說是最常見的了，它本質就是發送一個請求來取得服務器上的某一資源。資源通過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。
1，HEAD：HEAD和GET本質是一樣的，區別在於HEAD不含有呈現數據，而僅僅是HTTP頭信息。想象一個業務情景：欲判斷某個資源是否存在，我們通常使用GET，但這裏用HEAD則意義更加明確。2，PUT：這個方法比較少見。HTML表單也不支持這個。本質上來講， PUT和POST極爲相似，都是向服務器發送數據，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的數據存放位置由服務器自己決定。舉個例子：如一個用於提交博文的URL，/addBlog。如果用PUT，則提交的URL會是像這樣的”/addBlog/abc123”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交後由服務器告知客戶端。目前大部分博客都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務場景。
3，DELETE：刪除某一個資源。基本上這個也很少見，不過還是有一些地方比如amazon的S3雲服務裏面就用的這個方法來刪除資源。
4，POST：向服務器提交數據。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。
5，OPTIONS：這個方法很有趣，但極少使用。它用於獲取當前URL所支持的方法。若請求成功，則它會在HTTP頭中包含一個名爲“Allow”的頭，值是所支持的方法，如“GET, POST”。
其實還有一個TRACE方法，不過這個基本上不會用到，這裏就不介紹了。以上的六種方法，我們可以跟數據庫的CRUD增刪改查操作對應起來：
CREATE ：PUT
READ：GET
UPDATE：POST
DELETE：DELETE