## 常用經驗 - 在HTTP中，我們要通過 URL 進行資源的定位 >比如: > >要取 id=888 的用戶信息，我們就向/user/{id} 這個路徑發送請求， > >要取 id=888 的用戶的訂單列表，我們就向/user/{id}/orders 這個路徑發送請求 - 在HTTP 中，DEL ...
常用經驗
-
在HTTP中，我們要通過 URL 進行資源的定位
比如:
要取 id=888 的用戶信息，我們就向/user/{id} 這個路徑發送請求，
要取 id=888 的用戶的訂單列表，我們就向/user/{id}/orders 這個路徑發送請求
-
在HTTP 中，DELETE、PUT、GET請求應該是冪等的，而POST 則不是冪等的。所謂“冪等”指的是:對於一個介面採用同樣的參數請求一次和請求多次的結果是一致的，不會因為多次請求而產生副作用
-
在HTTP中，GET請求的響應是可以被緩存的，而DELETE、PUT、POST請求的響應是不可以被緩存的。客戶端、網關等可以根據情況對 GET 請求的響應進行緩存，從而提升性能
-
在HTTP中，伺服器端要通過狀態碼來反映資源獲取的結果
比如:
客戶端要獲取id-8的用戶，如果要獲取的用戶不存在，則伺服器返回的狀態碼為 404，而如果當前客戶端沒有許可權獲取這個用戶，伺服器返回的狀態碼為 403。再如，對於新增用戶請求，如果新增成功，伺服器返回的狀態碼為 201
優點
-
所有的資源都儘量通過URL來表示,URL的語義性更清晰
-
對所有類型資源的新增、刪除、修改、查詢操作都統一為向資源發送POST、DELETE.、PUT、GET 請求，介面統一且具有自描述性，減少了開發人員對介面文檔的依賴性
-
對於 GET、PUT、DELETE 等冪等的操作，網關、網路請求組件等可以對失敗的請求自動重試
-
網關等可以對 GET 請求進行緩存，能夠提升系統的訪問速度，而且降低伺服器的壓力
-
通過HTTP狀態碼反映伺服器端的處理結果，能夠統一錯誤碼，避免自定義錯誤碼帶來的不統一的問題
戶端也可以根據錯誤碼進行統一處理，比如對於 403 狀態碼，客戶端統一提示用戶去登錄
-
網關等系統可以根據狀態碼來分析系統的訪問數據，比如可以根據 HTTP狀態碼分析有多少成功的請求，有多少失敗的請求
缺點
- 真實系統中的資源非常複雜，很難清晰地進行資源的劃分
- 真實系統中的業務很複雜，並不是所有的操作都能簡單地對應到PUT、GET、DELETE、POST上
- 真實系統是在不斷進化的，一個操作最開始的時候被設計為冪等的 PUT，但是後來的版本又修改了邏輯，可能該操作就變成了不冪等的。如果調用者繼續對這個操作進行重試可能會有副作用
- 在 Restful 中，資源儘量通過 URL來定位，要儘量避免使用 QueryString 及請求報文體傳遞數據
- HTTP狀態碼的個數是有限的，特別是用於表示業務相關的錯誤碼主要在 4xx狀態碼段中,而業務系統中的錯誤非常複雜,僅通過 HTTP狀態碼來反映錯誤有時候會無法滿足要求
- 有的客戶端是不支持 PUT、DELETE 請求的。例如: 舊版本的程式
總結
REST 概念是用來指導我們設計介面的，而不是給開髮帶來麻煩的，它只是一個參考的風格，並不是一個必須遵守的規範，不能因為要遵守Restful 風格而影響開發進度及系統的穩定。項目開發的時候，需要根據項目特點、公司人員等多方面情況，確定一個符合項目情況的定製版 Restful 規範。
本文來自博客園，作者：笨笨的二黃子，轉載請註明原文鏈接：https://www.cnblogs.com/zwhdd/p/17669881.html
