REST中 @POST & @PUT 區別

「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.」html

上面的話就是說,若是一個方法重複執行屢次,產生的效果是同樣的,那就是idempotent(冪等)的,首先解釋冪等,冪等是數學的一個用語,對於單個輸入或者無輸入的運算方法,若是每次都是一樣的結果,則稱其是冪等的。對於兩個參數,若是傳入值相等,結果也等於每一個傳入值,則稱其爲冪等的,如min(a,b)。前端

在HTTP中,PUT被定義爲idempotent(冪等)的方法,POST則不是,這是一個很重要的區別。api

 

POST瀏覽器

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

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

 

PUT網絡

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

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

 

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

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個要淘汰的就是阻礙生產力發展的落後生產關係……

 

舉一個簡單的例子,假若有一個博客系統提供一個Web API,模式是這樣http://superblogging/blogs/post/{blog-name},很簡單,將{blog-name}替換爲咱們的blog名字,往這個URI發送一個HTTP PUT或者POST請求,HTTP的body部分就是博文,這是一個很簡單的REST API例子。咱們應該用PUT方法仍是POST方法?取決於這個REST服務的行爲是不是idempotent的,假如咱們發送兩個http://superblogging/blogs/post/Sample請求,服務器端是什麼樣的行爲?若是產生了兩個博客帖子,那就說明這個服務不是idempotent的,由於屢次使用產生了反作用了嘛;若是後一個請求把第一個請求覆蓋掉了,那這個服務就是idempotent的。前一種狀況,應該使用POST方法,後一種狀況,應該使用PUT方法。

相關文章
相關標籤/搜索