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

具體定義可以百度，我這裡就不貼了，光說我自己的理解

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

對於兩個引數，如果傳入值相等，結果也等於每個傳入值，則稱其為冪等的，如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

個人理解為：表現形式的狀態傳遞

1、只有一個介面交換xml來實現整個服務

目前我們的移動站點的服務就是類似的結構，我們有兩個URI介面/mapp/lead和/msdk/safepay

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

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

3、在2的基礎上使用了http verb，每個URI可以有不同的動作，充分利用了http協議，所以自然居然http協議的完整優勢，比如快取和健壯性

HTML4.0只支援POST和GET，所以無論DELETE還是PUT操作，都用POST去模擬了

在WEB開發者看來，就是如果有資料變動，就用POST，如果沒有，就用GET

所以目前中國使用者來看，PC端實現RESTful很困難，只有移動端支援Html5的瀏覽器，才能讓前端做出嘗試

4、現在似乎更加無法實際應用，Hypemedia control，也就是RESTful的本意，合理的架構原理和以網路為基礎的設計相結合，帶來一個更加方便、功能強大的通訊架構

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