表徵狀態轉移（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。

目前在三種主流的Web服務實現方案中，由於REST模式的Web服務與複雜的SOAP和XML-RPC對比來說明顯的更加簡潔，愈來愈多的web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。

應該是，作WEB服務，都必須掌握REST哦~~

Rest模式有四種操做，

POST /uri 建立
DELETE /uri/xxx 刪除
PUT /uri/xxx 更新或建立
GET /uri/xxx 查看

GET操做是安全的。所謂安全是指無論進行多少次操做，資源的狀態都不會改變。好比我用GET瀏覽文章，無論瀏覽多少次，那篇文章還在那，沒有變化。固然，你可能說每瀏覽一次文章，文章的瀏覽數就加一，這不也改變了資源的狀態麼？這並不矛盾，由於這個改變不是GET操做引發的，而是用戶本身設定的服務端邏輯形成的。

PUT，DELETE操做是冪等的。所謂冪等是指無論進行多少次操做，結果都同樣。好比我用PUT修改一篇文章，而後在作一樣的操做，每次操做後的結果並無不一樣，DELETE也是同樣。順便說一句，由於GET操做是安全的，因此它天然也是冪等的。

POST操做既不是安全的，也不是冪等的，好比常見的POST重複加載問題：當咱們屢次發出一樣的POST請求後，其結果是建立出了若干的資源。

安全和冪等的意義在於：當操做沒有達到預期的目標時，咱們能夠不停的重試，而不會對資源產生反作用。從這個意義上說，POST操做每每是有害的，但不少時候咱們仍是不得不使用它。

還有一點須要注意的就是，建立操做可使用POST，也可使用PUT，區別在於POST 是做用在一個集合資源之上的（/uri），而PUT操做是做用在一個具體資源之上的（/uri/xxx），再通俗點說，若是URL能夠在客戶端肯定，那麼就使用PUT，若是是在服務端肯定，那麼就使用POST，好比說不少資源使用數據庫自增主鍵做爲標識信息，而建立的資源的標識信息究竟是什麼只能由服務端提供，這個時候就必須使用POST。

關於GET POST 的混淆

先說相同點，只有瞭解了相同點以後才能理解爲何會發生混淆。二者都能向服務器發送數據，提交的「內容」[注1]的格式相同，都是var_1=value_1&var_2=value_2&....get 和 post 區別如字面，一個是get（獲取），一個是post（發送）。get用來告訴服務器須要獲取哪些內容（uri+query），向靜態頁面（uri）請求則直接返回文件內容給瀏覽器，向一個動態頁面請求時能夠提供查詢參數（query）以得到相應內容。post用來向服務器提交內容，主要是爲了提交，而不是爲了請求內容，就是說post的初衷並不要求服務器返回內容[注2]，只是提交內容讓服務器處理（主要是存儲或者處理以後再存儲）。get和post出現混淆是由於對提交的數據處理方法的濫用形成的，數據是無辜的。

混淆之一：將get提交的用來查詢的字段看成是存儲數據存入了服務器端文件或者數據庫。而後就誤覺得get是用來提交用於存儲的數據的。

混淆之二：編寫腳本在服務器端經過處理post提交的數據並返回內容。只要有數據，就能用來進行判斷，腳本怎寫是程序員的事，而不在意數據來源的形式（post、get，或者是本身預設值的常量）。這點功能上確實沒問題，只是背離的其初始目的而已。

因爲都是要傳送數據，且數據格式相同（即便數據格式不一樣，只要能提取出相應數據）。使用的時候不免出現張冠李戴，將get數據用來存儲、將post數據用來檢索返回數據。可是兩者仍是有區別的（主要是根據其用途而「人爲」[注3]形成的），get的長度限制在2048字節（由瀏覽器和服務器限制的，這是目前IE的數據，曾經是1024字節），很大程度上限制了get用來傳遞「存儲數據」的數據的能力，因此仍是老老實實用來作檢索吧；post則無此限制（只是HTTP協議規範沒有進行大小限制，但受限於服務器的處理能力），所以對於大的數據（通常來講須要存儲的數據可能會比較大，比2048字節大）的傳遞有自然的優點，誰讓它是 nature born post 呢。

get提交的數據是放在url裏，目的是靈活的向服務其提交檢索請求，能夠在地址欄隨時修改數據以變動須要獲取的內容，好比直接修改分頁的編號就跳到另一個分頁了（固然也多是 404）。post提交的數據放在http請求的正文裏，目的在於提交數據並用於服務器端的存儲，而不容許用戶過多的更改相應數據（主要是相對於在url 修改要麻煩不少，url的修改只要點擊地址欄輸入字符就能夠了），除非是專門跑來編輯數據的。

花邊：post和get的安全性在傳輸的層面上區別不大，可是採用url提交數據的get方式容易被人肉眼看到，或者出如今歷史紀錄裏，仍是可能被肉眼看到，都是一些本地的問題。

注1：我強調的是內容，至於http協議中的get和post的格式你們有興趣就本身看看吧。
注2：get方式主要是爲了得到預期內容，即uri+query相同時所獲得的內容應該是相同的。而post主要是提交內容，至因而否有必要返回頁面可能只是出於用戶體驗，好比註冊時返回你的註冊id，可是若是隻是返回一個「您已註冊成功」的相同頁面（即便你post的數據不同）也沒什麼好奇怪的。
注3：關於這個「人爲」，不是那麼貼切，get和post仍是有技術層面的區別的。可是從表象上看暫且這麼說吧，畢竟兩者的混淆也是「人爲」的。

======================

http://www.restapitutorial.com/lessons/httpmethods.html

Using HTTP Methods for RESTful Services

The HTTP verbs comprise a major portion of our 「uniform interface」 constraint and provide us the action counterpart to the noun-based resource. The primary or most-commonly-used HTTP verbs (or methods, as they are properly called) are POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations, respectively. There are a number of other verbs, too, but are utilized less frequently. Of those less-frequent methods, OPTIONS and HEAD are used more often than others.

Below is a table summarizing recommended return values of the primary HTTP methods in combination with the resource URIs:

HTTP Verb	CRUD	Entire Collection (e.g. /customers)	Specific Item (e.g. /customers/{id})
POST	Create	201 (Created), 'Location' header with link to /customers/{id} containing new ID.	404 (Not Found), 409 (Conflict) if resource already exists..
GET	Read	200 (OK), list of customers. Use pagination, sorting and filtering to navigate big lists.	200 (OK), single customer. 404 (Not Found), if ID not found or invalid.
PUT	Update/Replace	404 (Not Found), unless you want to update/replace every resource in the entire collection.	200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
PATCH	Update/Modify	404 (Not Found), unless you want to modify the collection itself.	200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.
DELETE	Delete	404 (Not Found), unless you want to delete the whole collection—not often desirable.	200 (OK). 404 (Not Found), if ID not found or invalid.

Below is a more-detailed discussion of the main HTTP methods. Click on a tab for more information about the desired HTTP method.

The POST verb is most-often utilized to **create** new resources. In particular, it's used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. In other words, when creating a new resource, POST to the parent and the service takes care of associating the new resource with the parent, assigning an ID (new resource URI), etc.

On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.

POST is neither safe nor idempotent. It is therefore recommended for non-idempotent resource requests. Making two identical POST requests will most-likely result in two resources containing the same information.

Examples:

POST http://www.example.com/customers
POST http://www.example.com/customers/12345/orders

PUT 仍是 POST ?

Using HTTP Methods for RESTful Services