平時的Rest開發，用到的都是GET,POST,PUT,DELETE類型的請求。
但Rest支持的請求類型不止前面4種，還有其他幾種。
下面部分轉自： https://www.html.cn/archives/9341
超文本傳輸協議（HTTP, HyperText Transfer Protocol）是一種無狀態的協議，它位於OSI七層模型的傳輸層。HTTP客戶端會根據需要構建合適的HTTP請求方法，而HTTP服務器會根據不同的HTTP請求方法做出不同的響應。
1. HTTP版本與HTTP請求方法
在HTTP的發展過程中，出現了很多HTTP版本，其中的大部分協議都是向下兼容的。在進行HTTP請求時，客戶端在請求時會告訴服務器它采用的協議版本號，而服務器則會在使用相同或者更早的協議版本進行響應。
HTTP/0.9
這是HTTP最早大規模使用的版，現已過時。在這個版本中 只有GET一種請求方法，在HTTP通訊也沒有指定版本號，也不支持請求頭信息。該版本不支持POST等方法，因此客戶端向服務器傳遞信息的能力非常有限。HTTP/0.9的請求只有如下一行：
GET www.itbilu.com
HTTP/1.0
這個版本是第一個在HTTP通訊中指定版本號的協議版本，HTTP/1.0至今仍被廣泛采用，特別是在代理服務器中。
HTTP/1.0支持：GET、POST、HEAD三種HTTP請求方法。
HTTP/1.1
HTTP/1.1是當前正在使用的版本。該版本默認采用持久連接，並能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。
HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五種HTTP請求方法。
HTTP/2
這個版本是最新發布的版本，於今年5月（2015年5月）做HTTP標准正式發布。HTTP/2通過支持請求與相應的多路重用來減少延遲，通過壓縮HTTP頭字段將協議開銷降到最低，同時增加了對請求優先級和服務器端推送的支持。
2. HTTP請求方法介紹
HTTP/1.1協議中共定義了8種HTTP請求方法，HTTP請求方法也被叫做“請求動作”，不同的方法規定了不同的操作指定的資源方式。服務端也會根據不同的請求方法做不同的響應。
GET
GET請求會顯示請求指定的資源。一般來說GET方法應該只用於數據的讀取，而不應當用於會產生副作用的非冪等的操作中。
GET會方法請求指定的頁面信息，並返回響應主體，GET被認為是不安全的方法，因為GET方法會被網絡蜘蛛等任意的訪問。
HEAD
HEAD方法與GET方法一樣，都是向服務器發出指定資源的請求。但是，服務器在響應HEAD請求時不會回傳資源的內容部分，即：響應主體。這樣，我們可以不傳輸全部內容的情況下，就可以獲取服務器的響應頭信息。HEAD方法常被用於客戶端查看服務器的性能。
POST
POST請求會 向指定資源提交數據，請求服務器進行處理，如：表單數據提交、文件上傳等，請求數據會被包含在請求體中。POST方法是非冪等的方法，因為這個請求可能會創建新的資源或/和修改現有資源。
PUT
PUT請求會身向指定資源位置上傳其最新內容，PUT方法是冪等的方法。通過該方法客戶端可以將指定資源的最新數據傳送給服務器取代指定的資源的內容。
DELETE
DELETE請求用於請求服務器刪除所請求URI（統一資源標識符，Uniform Resource Identifier）所標識的資源。DELETE請求后指定資源會被刪除，DELETE方法也是冪等的。
CONNECT
CONNECT方法是HTTP/1.1協議預留的，能夠將連接改為管道方式的代理服務器。通常用於SSL加密服務器的鏈接與非加密的HTTP代理服務器的通信。
OPTIONS
OPTIONS請求與HEAD類似，一般也是用於客戶端查看服務器的性能。 這個方法會請求服務器返回該資源所支持的所有HTTP請求方法，該方法會用’*’來代替資源名稱，向服務器發送OPTIONS請求，可以測試服務器功能是否正常。JavaScript的XMLHttpRequest對象進行CORS跨域資源共享時，就是使用OPTIONS方法發送嗅探請求，以判斷是否有對指定資源的訪問權限。 允許
TRACE
TRACE請求服務器回顯其收到的請求信息，該方法主要用於HTTP請求的測試或診斷。
HTTP/1.1之后增加的方法
在HTTP/1.1標准制定之后，又陸續擴展了一些方法。其中使用中較多的是 PATCH?方法：
PATCH
PATCH方法出現的較晚，它在2010年的RFC 5789標准中被定義。PATCH請求與PUT請求類似，同樣用於資源的更新。二者有以下兩點不同：
- 但
PATCH一般用於資源的部分更新，而PUT一般用於資源的整體更新。 - 當資源不存在時，
PATCH會創建一個新的資源，而PUT只會對已在資源進行更新。
安全性與冪等性
關於HTTP請求采用的這些個方法，具有兩個基本的特性，即“安全性”和“冪等性”。
對於上述7種HTTP方法，GET、HEAD和OPTIONS均被認為是安全的方法，因為它們旨在實現對數據的獲取，並不具有“邊界效應”。至於其它4個HTTP方法，由於它們會導致服務端資源的變化，所以被認為是不安全的方法。
冪等性（Idempotent）是一個數學上的概念，在這里表示發送一次和多次請求引起的邊界效應是一致的。在網速不夠快的情況下，客戶端發送一個請求后不能立即得到響應，由於不能確定是否請求是否被成功提交，所以它有可能會再次發送另一個相同的請求，冪等性決定了第二個請求是否有效。
上述3種安全的HTTP方法（GET、HEAD和OPTIONS）均是冪等方法。由於DELETE和PATCH請求操作的是現有的某個資源，所以它們是冪等方法。對於PUT請求，只有在對應資源不存在的情況下服務器才會進行添加操作，否則只作修改操作，所以它也是冪等方法。至於最后一種POST，由於它總是進行添加操作，如果服務器接收到兩次相同的POST操作，將導致兩個相同的資源被創建，所以這是一個非冪等的方法。
當我們在設計Web API的時候，應該盡量根據請求HTTP方法的冪等型來決定處理的邏輯。由於PUT是一個冪等方法，所以攜帶相同資源的PUT請求不應該引起資源的狀態變化，如果我們在資源上附加一個自增長的計數器表示被修改的次數，這實際上就破壞了冪等型。
無狀態性
RESTful只要維護資源的狀態，而不需要維護客戶端的狀態。對於它來說，每次請求都是全新的，它只需要針對本次請求作相應的操作，不需要將本次請求的相關信息記錄下來以便用於后續來自相同客戶端請求的處理。
對於上面我們介紹的RESTful的這些個特性，它們都是要求我們為了滿足這些特征做點什么，唯有這個無狀態卻是要求我們不要做什么，因為HTTP本身就是無狀態的。舉個例子，一個網頁通過調用Web API分頁獲取符合查詢條件的記錄。一般情況下，頁面導航均具有“上一頁”和“下一頁”鏈接用於呈現當前頁的前一頁和后一頁的記錄。那么現在有兩種實現方式返回上下頁的記錄。
- Web API不僅僅會定義根據具體頁碼的數據查詢定義相關的操作，還會針對“上一頁”和“下一頁”這樣的請求定義單獨的操作。它自身會根據客戶端的Session ID對每次數據返回的頁面在本地進行保存，以便能夠知道上一頁和下一頁具體是哪一頁。
- Web API只會定義根據具體頁碼的數據查詢定義相關的操作，當前返回數據的頁碼由客戶端來維護。
第一種貌似很“智能”，其實就是一種畫蛇添足的作法，因為它破壞了Web API的無狀態性。設計無狀態的Web API不僅僅使Web API自身顯得簡單而精煉，還因減除了針對客戶端的“親和度（Affinty）”使我們可以有效地實施負載均衡，因為只有這樣集群中的每一台服務器對於每個客戶端才是等效的。