RESTful的正確姿勢

很多人都有這樣的疑問：

rest（英文：representational state transfer，簡稱rest）描述了乙個架構樣式的網路系統，比如 web 應用程式。它首次出現在 2000 年 roy fielding 的博士**中，roy fielding是 http 規範的主要編寫者之一。在目前主流的三種web服務互動方案中，rest相比於soap（****** object access protocol，簡單物件訪問協議）以及xml-rpc更加簡單明瞭，無論是對url的處理還是對payload的編碼，rest都傾向於用更加簡單輕量的方法設計和實現。值得注意的是rest並沒有乙個明確的標準，而更像是一種設計的風格。 rest 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 restful。 restful特點包括： 1、每乙個uri代表1種資源； 2、客戶端使用get、post、put、delete4個表示操作方式的動詞對服務端資源進行操作：get用來獲取資源，post用來新建資源（也可以用於更新資源），put用來更新資源，delete用來刪除資源； 3、通過操作資源的表現形式來操作資源； 4、資源的表現形式是xml或者html；

5、客戶端與服務端之間的互動在請求之間是無狀態的，從客戶端到服務端的每個請求都必須包含理解請求所必需的資訊。

這裡以乙個物流系統為例定義一組介面，這裡需要完成的功能如下

通過需求可以清晰的看到兩個資源，物流運單和發票，分別定義為delivery和invoice，根據rest風格的特點，定義如下介面

錯誤碼：

查詢物流運單

rest建議使用get來獲取資源。

查詢所有：
url:[get]/delivery
response: [ ,  ]
根據id查詢
url:[get]/delivery/
response: 
多條件查詢
url:[get]/delivery/?mot=&carrier=...
response: [ ,  ]

錯誤碼：

在實際應用中，這個查詢被挑戰的最多

修改物流運單

rest建議使用put來獲取資源。

修改物流運單介面
url:[put]/delivery/
request: 
response:

錯誤碼：

在實際應用中，這個修改操作還面臨著批量修改和部分修改的挑戰

刪除物流運單

rest建議使用delete來獲取資源。

刪除物流運單介面
url:[delete]/delivery/
response:

實際操作還有批量刪除的場景

批量上傳物流運單

rest沒建議

發票管理介面。參照物流運輸單來一套就好了。

統計介面

統計資訊是發票和運單的綜合資料，我們稱他為分攤後發票，是每個發票在單個運單上的金額資訊，記為delivery-invoice。在後台可以有乙個元件在自動更新。雖然這個介面是乙個查詢介面，但是查詢的內容不是原始資料，是統計資料，不知道應該叫什麼url了。

技術和規範都是服務於業務的，在業務需求的推動下，所有的技術和規範必須與時俱進。針對上面提到的問題，做做了一些調整。

批量建立

建立物流運單介面
url:[post]/delivery
head: rest_command=batch_create
request: 
response: , ...]
}

查詢物流運單

修改物流運單

刪除物流運單

刪除操作在刪除物件不存在時直接返回，因為期望結果和當前結果一致的。

批量上傳物流運單

批量上傳可以按照批量建立的介面做。更新rest_command=batch_upload。

統計介面

統計資訊是發票和運單的綜合資料，我們稱他為分攤後發票，是每個發票在單個運單上的金額資訊，記為delivery-invoice。在後台可以有乙個元件在自動更新。雖然這個介面是乙個查詢介面，但是查詢的內容不是原始資料，是統計資料，所以命名為delivery-invoice-report。

url:[post]/delivery-invoice-report
head: rest_command=generate
request: 
response: 
}

RESTful的正確姿勢

正確姿勢的verticle align

正確上網的姿勢

正確的打日誌姿勢

RESTful的正確姿勢

正確姿勢的verticle align

正確上網的姿勢

正確的打日誌姿勢

相關推薦