（轉）理解POST和PUT的區別，順便提下RESTful

這兩個方法咋一看均可以更新資源，可是有本質區別的

具體定義能夠百度，我這裏就不貼了，光說我本身的理解

首先解釋冪等，冪等是數學的一個用語，對於單個輸入或者無輸入的運算方法，若是每次都是一樣的結果，則稱其是冪等的

對於兩個參數，若是傳入值相等，結果也等於每一個傳入值，則稱其爲冪等的，如min(a,b)

POST

用於提交請求，能夠更新或者建立資源，是非冪等的

舉個例子，在咱們的支付系統中，一個api的功能是建立收款金額二維碼，它和金額相關，每一個用戶能夠有多個二維碼，若是連續調用則會建立新的二維碼，這個時候就用POST

PUT

用於向指定的URI傳送更新資源，是冪等的

仍是那個例子，用戶的帳戶二維碼只和用戶關聯，並且是一一對應的關係，此時這個api就能夠用PUT，由於每次調用它，都將刷新用戶帳戶二維碼

好比一個接口用於用戶生成，接收的數據是用戶名、密碼等相關信息，則用POST

RESTful建議全部的URI都是對應資源，因此建立用戶不該該理解爲一個行爲，在此將此接口命名爲:

/user/creation

每次調用它都會新建一個用戶（假定用戶名能夠重複）

而PUT方法更加關心一個具體資源對應的URI，好比更新當前用戶信息，這裏能夠用PUT

/user/me/update

這裏用me來指代當前用戶，若是是針對更多用戶適用的接口，能夠考慮

/user/{uid}/update

注意屢次調用同一接口，只要提交的數據一致，用戶信息每次結果就會一致，即產生一樣的結果：服務器端某個具體的資源獲得了更新

當須要以更新的形式來修改某一具體資源的時候，如何判斷用PUT仍是POST呢？

很簡單，若是該更新對應的URI屢次調用的結果一致，則PUT

好比更新某個blog文章，由於該文章具備單一的具體URI，因此每次更新提交相同的內容，結果都一致

/blog/{document_id}/update

在每次更新提交相同的內容，最終的結果不一致的時候，用POST

舉個很常見的例子，一個接口的功能是將當前餘額減一個值，每次提交指定該值爲100，接口以下

/amount/deduction

調用一次，你的餘額-100，調用兩次，餘額-200

這個時候就用POST

RESTful的4種層次

Representational status transfer

我的理解爲：表現形式的狀態傳遞

一、只有一個接口交換xml來實現整個服務

目前咱們的移動站點的服務就是相似的結構，咱們有兩個URI接口/mapp/lead和/msdk/safepay

二、每個資源對應一個具體的URI，比1好維護，可是問題依然很明顯，資源版本更新會引入時間戳維護，資源的獲取和更新修改必須對應不一樣的URI

目前PC主站和移動站點的靜態內容（包括html文件）都是這種形式

三、在2的基礎上使用了http verb，每一個URI能夠有不一樣的動做，充分利用了http協議，因此天然竟然http協議的完整優點，好比緩存和健壯性

HTML4.0只支持POST和GET，因此不管DELETE仍是PUT操做，都用POST去模擬了

在WEB開發者看來，就是若是有數據變更，就用POST，若是沒有，就用GET

因此目前中國用戶來看，PC端實現RESTful很困難，只有移動端支持Html5的瀏覽器，才能讓前端作出嘗試

四、如今彷佛更加沒法實際應用，Hypemedia control，也就是RESTful的本意，合理的架構原理和以網絡爲基礎的設計相結合，帶來一個更加方便、功能強大的通訊架構

這就有點虛無縹緲了，不過是一個努力的方向，想一想看，之後要繳水費了，打開瀏覽器，輸入我要繳水費，就自動定位+自動下單+自動付款+自動展現結果，完成整個繳水費的過程，這是多麼方便的領悟！gwy要失業了有木有，那幫吃白飯作很簡單的事情的，生產力發展第1個要淘汰的就是阻礙生產力發展的落後生產關係……