一、本文大綱
RESTful風格API的好處
RESTful API的設計風格
二、RESTful風格API的好處
API：顧名思義（Application Programming Interface）是一組編程接口規範，客戶端與服務端通過請求響應進行數據通信。REST（Representational State Transfer）決定了接口的形式與規則。RESTful是基於http方法的API設計風格，而不是一種新的技術.要達到的效果就是：
看URI就知道需要什麼資源
看http method方法就知道針對資源做什麼動作
看http 狀態碼就知道動作的結果如何
對接口開發提供了一種可以廣泛適用的規範，為前端後端交互減少了接口交流的口舌成本，是約定大於配置的體現。通過下面的設計，大家來理解一下這三句話。
當然也不是所有的接口，都能用REST的形式來表述。在實際工作中，靈活運用，我們用RESTful風格的目的是為大家提供統一標準，避免不必要的溝通成本的浪費，形成一種通用的風格。就好比大家都知道：伸出大拇指表示「你很棒「的意思，絕大部分人都明白，因為你了解了這種風格習慣。但是不排除有些地區伸出大拇指表示其他意思，就不適合使用！
二、RESTful API的設計風格
2.1、REST 是面向資源的（名詞）
RESTful API 通過 URI 對外暴露資源時，規範的做法是不要在 URI 中出現動詞。如：
2.2、用HTTP方法體現對資源的操作（動詞）
GET ： 獲取、讀取資源
POST ： 添加資源
PUT ： 修改資源
DELETE ： 刪除資源
2.3. HTTP狀態碼
通過HTTP狀態碼體現動作的結果,不要自定義
200 OK 400 Bad Request 500 Internal Server Error
在 APP 與 API 的交互當中，其結果逃不出這三種狀態：
所有事情都按預期正確執行完畢 - 成功
APP 發生了一些錯誤 – 客戶端錯誤（如：校驗用戶輸入身份證，結果輸入的是軍官證，就是客戶端輸入錯誤）
API 發生了一些錯誤 – 伺服器端錯誤（各種編碼bug或服務內部自己導致的異常）
這三種狀態與上面的狀態碼是一一對應的。如果你覺得這三種狀態，分類處理結果太寬泛，http-status code狀態碼還有很多。建議還是要遵循KISS(Keep It Stupid and Simple)原則，上面的三種狀態碼完全可以覆蓋99%以上的場景。這三個狀態碼大家都記得住，而且非常常用，多了就不一定了。
2.4. Get方法和查詢參數不應該改變數據
改變數據的事交給POST、PUT、DELETE
2.5. 使用複數名詞
/dogs 而不是 /dog
2.6. 複雜資源關係的表達
GET /cars/820/drivers/ 返回 使用過編號820汽車的所有司機
GET /cars/820/drivers/8 返回 使用過編號820汽車的8號司機
2.7. 高級用法:HATEOAS
HATEOAS:Hypermedia as the Engine of Application State 超媒體作為應用狀態的引擎。
RESTful API最好做到HATEOAS，即返回結果中提供連結，連向其他API方法，使得用戶不查文檔，也知道下一步應該做什麼。比如：對api.example.com接口發出GET請求，會得到下面的JSON響應結果。
上面響應結果，JSON文本中的link屬性，用來說明API消費者可以知道下一步可以調用什麼API或者該調用什麼API。
2.8. 資源過濾、排序、選擇和分頁的表述
2.9. 版本化你的API
強制性增加API版本聲明，不要發布無版本的API。如：/api/v1/blog
面向擴展開放，面向修改關閉：也就是說一個版本的接口開發完成測試上線之後，我們一般不會對接口進行修改，如果有新的需求就開發新的接口進行功能擴展。這樣做的目的是：當你的新接口上線後，不會影響使用老接口的用戶。如果新接口目的是替換老接口，也不要在v1版本原接口上修改，而是開發v2版本接口，並聲明v1接口廢棄！
寫在最後
通過搜-suo-查詢「字母哥博客」，更多精品知識等待你！
本號只做持續的知識輸出，希望您能關注、評論、轉發！您的支持是我不竭的創作動力！讓知識產生價值、讓程式設計師改變世界！