首先解釋冪等，冪等是數學的壹個用語，對於單個輸入或者無輸入的運算方法，如果每次都是同樣的結果，則稱其是冪等的
對於兩個引數，如果傳入值相等，結果也等於每個傳入值，則稱其為冪等的，如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主站和移動站點的靜態內容（包括檔案）都是這種形式
3、在2的基礎上使用了 verb，每個URI可以有不同的動作，充分利用了協議，所以自然居然協議的完整優勢，比如快取和健壯性
HTML4.0只支援POST和GET，所以無論DELETE還是PUT操作，都用POST去模擬了
在WEB開發者看來，就是如果有資料變動，就用POST，如果沒有，就用GET
所以目前中國使用者來看，PC端實現RESTful很困難，只有移動端支援Html5的瀏覽器，才能讓前端做出嘗試
4、現在似乎更加無法實際應用，Hypemedia control，也就是RESTful的本意，合理的架構原理和以網路為基礎的設計相結合，帶來壹個更加方便、功能強大的通訊架構
在HTTP中，PUT被定義為idempotent的方法，POST則不是，這是壹個很重要的區別。
“Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.”
上面的話就是說，如果壹個方法重復執行多次，產生的效果是壹樣的，那就是idempotent的。
REST 定義了壹組體系架構原則，您可以根據這些，包括使用不同語言編寫的客戶端如何通過 HTTP 處理和傳輸資源狀態。所以在事實上，REST 對 Web的影響非常大，由於其使用相當方便，已經普遍地取代了基於 SOAP 和 WSDL 的介面設計。在多年以後的今天，REST的主要框架已經開始雨後春筍般的出現。
post[英] [p?ust] [美] [post] n. 郵件；郵政；柱，樁，桿；崗位；
vt. 張貼；宣布；設崗；郵寄；
vi. 快速行進；
adj. 有關賽跑（或賽馬，賽狗）起點標誌的；
adv. 〈外〉在後；用急件[驛馬]；趕緊地，火速地；
put[英] [put] [美] [p?t] vt. 放；表達；給予（重視、信任、價值等）；使處於（某種狀態）；
vt.& vi. 使感覺到；使受到…的影響；
vi. 說；猛推；將…送往；使與…連線；
n. [方]笨蛋，怪人；對策；
adj. 固定的；不動的；
restful[英] [?restf?l] [美] [?r?stf?l] adj. 平靜的，悠閑的，讓人得到休息的；安生；
post 和 put 的區別POST請求的URI表示處理該封閉實體的資源，該資源可能是個資料接收過程、某種協議的閘道器、或者接收註解的獨立實體。然而，PUT請求中的URI表示請求中封閉的實體-使用者代理知道URI的目標，並且伺服器無法將請求應用到其他資源。如果伺服器希望該請求應用到另壹個URI，就必須傳送壹個301響應；使用者代理可通過自己的判斷來決定是否轉發該請求。
HTTP/1.1沒有定義壹個PUT請求如何影響原始伺服器的狀態。
PUT請求必須遵守資訊傳輸要求。
除非另有說明，PUT請求中的實體頭部應該用於PUT建立或修改的資源上。
restful和soap的區別rest輕量級，SOAP重量級；rest學習起來比較簡單，容易上手，SOAP相對來說難些；rest能通過形式的直接呼叫，基於JSON，SOAP通過XML傳輸；rest效率和速度來說相對快些，SOAP則稍遜壹籌
webservice和restful的區別REST是壹種架構風格，其核心是面向資源，REST專門針對網路應用設計和開發方式，以降低開發的復雜性，提高系統的可伸縮性。REST提出設計概念和準則為：
1.網路上的所有事物都可以被抽象為資源(resource)
2.每壹個資源都有唯壹的資源標識(resource identifier)，對資源的操作不會改變這些標識
3.所有的操作都是無狀態的
REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網路資源)只需要四種行為：建立，獲取，更新和刪除就可以完成相關的操作和處理。您可以通過統壹資源識別符號（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規範定義的。其核心操作只有GET,PUT,POST,DELETE。
由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分散式，叢集都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。
對於SOAP Webservice和Restful Webservice的選擇問題，首先需要理解就是SOAP偏向於面向活動，有嚴格的規範和標準，包括安全，事務等各個方面的內容，同時SOAP強調操作方法和操作物件的分離，有WSDL檔案規範和XSD檔案分別對其定義。而REST強調面向資源，只要我們要操作的物件可以抽象為資源即可以使用REST架構風格。
REST ful 應用問題
是否使用REST就需要考慮資源本身的抽象和識別是否困難，如果本身就是簡單的類似增刪改查的業務操作，那麽抽象資源就比較容易，而對於復雜的業務活動抽象資源並不是壹個簡單的事情。比如校驗使用者等級，轉賬，事務處理等，這些往往並不容易簡單的抽象為資源。
其次如果有嚴格的規範和標準定義要求，而且前期規範標準需要指導多個業務系統整合和開發的時候，SOAP風格由於有清晰的規範標準定義是明顯有優勢的。我們可以在開始和實現之前就嚴格定義相關的介面方法和介面傳輸資料。
簡單資料操作，無事務處理，開發和呼叫簡單這些是使用REST架構風格的優勢。而對於較為復雜的面向活動的服務，如果我們還是使用REST，很多時候都是仍然是傳統的面向活動的思想通過轉換工具再轉換得到REST服務，這種使用方式是沒有意義的。
效率和易用性
SOAP協議對於訊息體和訊息頭都有定義，同時訊息頭的可擴充套件性為各種網際網路的標準提供了擴充套件的基礎，WS-*系列就是較為成功的規範。但是也由於SOAP由於各種需求不斷擴充其本身協議的內容，導致在SOAP處理方面的效能有所下降。同時在易用性方面以及學習成本上也有所增加。
REST被人們的重視，其實很大壹方面也是因為其高效以及簡潔易用的特性。這種高效壹方面源於其面向資源介面設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有壹個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為資料承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源資訊
安全性
技術沒有好壞，只有是不是合適，壹種好的技術和思想被誤用了，那麽就會得到反效果。REST和SOAP各自都有自己的優點，同時如果在壹些場景下如果去改造REST，其實就會走向SOAP（例如安全）。
REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麽設計模式將會占據主導地位沒有什麽意義，關鍵還是看應用場景。
同時很重要壹點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，效能上不去，安全又保證不了。
成熟度
SOAP雖然發展到現在已經脫離了初衷，但是對於異構環境服務釋出和呼叫，以及廠商的支援都已經達到了較為成熟的情況。不同平臺，開發語言之間通過SOAP來互動的web service都能夠較好的互通。
由於沒有類似於SOAP的權威性協議作為規範，REST實現的各種協議僅僅只能算是私有協議，當然需要遵循REST的思想，但是這樣細節方面有太多沒有約束的地方。REST日後的發展所走向規範也會直接影響到這部分的設計是否能夠有很好的生命力。
restful和的區別REST 定義了壹組體系架構原則，您可以根據這些，包括使用不同語言編寫的客戶端如何通過 HTTP 處理和傳輸資源狀態。所以在事實上，REST 對 Web的影響非常大，由於其使用相當方便，已經普遍地取代了基於 SOAP 和 WSDL 的介面設計。在多年以後的今天，REST的主要框架已經開始雨後春筍般的出現。
個人理解：
（壹） 首先REST只是壹種風格，不是壹種標準
（二） REST是以資源為中心的
（三） REST充分利用或者說極端依賴HTTP協議
壹．對於今天正在吸引如此多註意力的最純粹形式的 REST Web 服務，其具體實現應該遵循以下基本設計原則：
1.1．顯式地使用不同的 HTTP 請求方法
1.2．無狀態
1.3．公開目錄結構式的 URI(通過邏輯URI定位資源)。
1.1．顯式地使用不同的 HTTP 請求方法
我們在 Web 應用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構中，用不同的 HTTP 請求方法來處理對資源的 CRUD（建立、讀取、更新和刪除）操作：
若要在伺服器上建立資源，應該使用 POST 方法。
若要檢索某個資源，應該使用 GET 方法。
若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
若要刪除某個資源，應該使用 DELETE 方法。
PHP中put和post區別1. 使用支援和範圍的區別：
PHP提供了對PUT方法的支援，在Http定義的與伺服器的互動方法中，PUT是把訊息本體中的訊息傳送到壹個URL，形式上跟POST類似;
PHP 提供對諸如 Netscape Composer 和 W3C Amaya 等客戶端使用的 HTTP PUT 方法的支援;
PHP 4 中，必須使用標準的輸入流來讀取壹個 HTTP PUT 的內容;
PUT方法沒有POST方法使用廣泛，但PUT方法卻是向伺服器上傳檔案最有效率的方法：
2.上傳過程的區別：
POST上傳檔案時，通常需要將所有的資訊組合成multipart 傳送過去，然後伺服器再解碼這些資訊，解碼過程則必不可少的會消耗記憶體和CPU資源，這種現象在上傳大檔案時尤其明顯；
PUT方法則允許妳通過與伺服器建立的socket連結傳遞檔案的內容，而不附帶其他的資訊，效果上更直接；
3.上傳效果的區別：
PHP 接受到 PUT 方法的請求時，會把上傳的檔案儲存到和其它用 POST 方法處理過的檔案相同的臨時目錄；請求結束時，臨時檔案將被刪除。
用來處理 PUT 的 PHP 指令碼必須將該檔案拷貝到其它的地方；
4. POST和PUT請求根本區別
POST請求的URI表示處理該封閉實體的資源，該資源可能是個資料接收過程、某種協議的閘道器、或者接收註解的獨立實體；
PUT請求中的URI表示請求中封閉的實體-使用者代理知道URI的目標；
伺服器無法將請求應用到其他資源；
如果伺服器希望該請求應用到另壹個URI，就必須傳送壹個301響應；
使用者代理可通過自己的判斷來決定是否轉發該請求；
get和post的區別，妳真的理解嗎get是收到得到 post 發出壹進壹出就是根本區別
He is ( ) a coat Ain B putting on C wearing 選什麽？ 順便講下in put on wear的區別選C。
in強調穿著什麽樣的衣服（這裏壹般 用in引導的介詞短語 作定語。）；
例：The girl in a blue blouse is my sister.
in a blue blouse是介詞短語，在句中作為定語來修飾the girl。
put on強調穿上衣服的動作，壹般用現在進行時；
例：The girl is putting on a blue blouse.
put on是行為動詞的固定搭配。
wear強調穿著某衣服的狀態。
例：The girl wears a blue blouse.
wear意為“穿著”。