個人感覺寫的不錯，簡單明瞭，看了一大堆理論之後，看這個比較舒服，所以無恥的轉載了，

原文連結：http://www.lifelaf.com/blog/?p=156

在RESTful的Web世界裡，我們真正可以操作的Request型別其實很少，HTTP僅提供了寥寥無幾的幾種Request，其中絕大多數Web操作都是由以下四種Request來完成的：

1. HTTP GET: 獲取資源
2. HTTP PUT/POST: 建立/新增資源
3. HTTP PUT: 修改資源
4. HTTP DELETE: 刪除資源

本文將介紹上述四種Request型別的使用，同時也會簡略介紹HEAD與OPTIONS請求。

參考書籍：《RESTful Web Services》, Chapter 4, “The Resource-Oriented Architecture”

GET, PUT和DELETE

GET請求用於向Server端獲取資源，而DELETE請求則用於刪除Server端的某個資源。GET的Response一般包含資源的內容，而DELETE的Response可能包含一些狀態資訊(刪除成功或者失敗)，也可能什麼都不包含。
比如：GET /web/blog/3 這個請求會獲取第三篇blog的內容，而DELETE /web/blog/3 這個請求則會刪除第三篇blog。

PUT請求用於在Server端建立新的資源 (create)，或者對已有資源進行修改 (modify)。PUT請求中一般會包含該新資源的內容。
比如：PUT /web/blog 這個請求會在Server端建立一個新的資源，資源名稱是blog；而PUT /web/blog/3 這個請求則會修改第三篇blog(用新的內容來覆蓋舊的)。

POST

POST請求也可用於在Server端建立新資源，但是在RESTful的世界裡，POST請求被定義為建立“從屬資源”(擁有父資源的資源) (add)。這話比較拗口，看一下例子可能會清晰很多：

在Server端沒有/web/blog的情況下，使用PUT /web/blog請求可以在Server端建立blog資源。blog資源建立好之後，可以使用POST /web/blog來新增一篇新的blog文章，POST請求成功後，我們就擁有了/web/blog/1這個資源。假如當前已經有了三篇blog (/web/blog/1, /web/blog/2和/web/blog/3)，那麼POST /web/blog將在Server端新增第四篇blog文章(/web/blog/4) — 在這個場景中，/web/blog/1, /web/blog/2, /web/blog/3和/web/blog/4都是“從屬資源”(擁有/web/blog這個父資源的資源)。

如何來判斷某次Request涉及的資源是從屬資源呢？除了從概念邏輯上判斷外，還有一個簡便的方法來判定：對於POST請求來說，將要被新增的“從屬資源”是URI未知的 — 在POST /web/blog請求新增新的一篇blog文章的時候，client並不知道這會是第幾篇blog，也不知道該blog建立後的URI是什麼(/web/blog/35? 還是/web/blog/42?)。與此相反，PUT請求建立、修改資源的時候，client端清楚的知道對應的URI (PUT /web/blog可以建立blog資源；在/web/blog已經存在的情況下，PUT /web/blog可以修改blog資源的設定；而PUT /web/blog/3則可以對某一篇特定的blog文章進行修改)。

除了新增新的“從屬資源”，POST請求還有一種應用場景：對某個特定資源增補內容(append)。比如，對於第三篇blog，在blog的最後，新增一段內容 (POST /web/blog/3)。

對於PUT和POST的區別，我們總結為：

PUT用於建立(Create)或修改(Modify)，而POST用於新增(Add)或增補(Append)

根據上述總結可推論，在PUT和POST的屬性之間，還有一個重要的區別：PUT是冪等的(Idempotent)，而POST不是 — 同一個操作連續進行多次，對於PUT而言其效果與只進行一次相同，但對於POST而言，每一次操作都會對Server端產生影響。

HEAD和OPTIONS

HEAD請求用於獲取某個資源的元資料(metadata)–比如，該資源是否存在，該資源的內容長度是多少等等。

OPTIONS請求用於獲取某個資源所支援的Request型別，在OPTIONS請求的Response中會包含Allow頭資訊，比如：

Allow: GET HEAD

上述例子表示該資源只支援GET請求與HEAD請求。

值得注意的是，在OPTIONS請求中，不同的Request頭資訊會影響最終返回的Response結果。比如，在OPTIONS請求中加入正確的Authorization資訊，得到的訪問許可權就可能更高。

轉載自：https://blog.csdn.net/xluren/article/details/40538783