一、什麼是RESTFul
RESTful是基於http方法的API設計風格而不是一種技術。可以說使用這種設計風格我們看到url就知道要什麼樣的資源、看到http method就知道要針對資源幹什麼、看到http的 status code就知道結果是什麼。使用RESTFul風格的api規範了程序員的代碼開發，爲前後端的交互減少了接口交流的口舌成本。
二、RESTFul風格的具體體現
2.1 REST 面向資源的（名詞）
REST通過URI暴露資源的時候，會強調不要再 URI 中出現的動詞，比如：
| 不符合REST的接口的URI | 符合REST接口的URI | 功能 |
|---|---|---|
| GET /api/getDog | GET /api/dogs/{id} | 獲取一個小狗狗對象 |
| GET /api/getDogs | GET /api/dogs | 獲取所有小狗狗對象 |
| GET /api/addDog | POST /api/dogs | 添加一個小狗狗對象 |
| GET /api/editDog/{id} | PUT /api/dogs/{id} | 修改一個小狗狗對象 |
| GET /api/deleteDog/{id} | DELETE /api/dogs/{id} | 刪除一個小狗狗對象 |
從上面的表格中我們可以看出，RESTFul風格的接口通過 URI 來暴露資源的時候裏面是沒有動詞的
2.2. 那麼問題來了，那麼怎樣體現對資源的操作呢
2.2.1 用HTTP方法體現對資源的操作
| 方法 | 功能 |
|---|---|
| GET | 獲取資源 |
| POST | 添加資源 |
| PUT | 修改資源 |
| DELETE | 刪除資源 |
2.3 HTTP狀態碼
通過 HTTP 狀態碼來體現狀態的結果，結果無非是兩種情況，成功、客戶端錯誤、服務器端錯誤
| 狀態碼 | 顯示的消息 | 表示的意義 |
|---|---|---|
| 200 | OK | 所有事情按照預期正確執行完畢 - 成功 |
| 400 | Bad Request | API發生了一些錯誤 - 客戶端錯誤 |
| 500 | Internal Server Error | API 發生了一些錯誤 - 服務器端錯誤 |
2.4 相關注意事項
- Get方法和查詢參數不應該改變數據，改變數據的事情交給POST、PUT、DELETE
- 使用複數名詞，而不要使用單數名詞
- 複雜資源關係的表達
GET /cars/711/drivers/ 返回使用 car 711的所有司機
GET /cars/711/drivers/4 返回使用car 711的4號司機
2.6高級用法：：HATEOAS
HATEOAS 的全稱爲 Hypermedia as the Engine of Application State（超媒體作爲應用狀態的引擎），什麼意思呢，就是返回結果中提供鏈接，連向其它API方法，使得用戶不查文檔也知道下一步應該做什麼。
例子如下：
{
"link":{
"rel":"collection https://www.example.com/zoos",
"href":"https://api.example.com/zoos",
"title":"List of zoos",
"type":"application/vnd.yourformat+json"
}
}
這裏表示，文檔中有一個link屬性，用戶讀取這個屬性就知道下一步該調用什麼API了。
2.8爲集合提供過濾、排序、選擇和分頁等功能
Filtering過濾：
使用唯一的查詢參數進行過濾：
GET /car?color=red 返回紅色的cars
GET /car?seats<=2 返回小於兩座位的cars集合
Sorting排序：
允許對多個字段進行排序
GET /cars?sort=-manufactor,+model
這個意思是返回根據生產者降序和模型升序排列的car集合，減號表示倒序，加號表示升序
Filed selection
移動端能夠顯示其中的一些字段，它們其實不需要一個資源的所有字段，給API消費者選擇一個字段的能力，這樣會降低網絡流量，提高API的可用性。
GET /cars?fileds=manufactor,model,id,color
Paging分頁
使用 limit 和 offfset ，實現分頁，缺省limit=20 和offset =0:
/cars?offset=10&limit=5
2.9版本化你的API
使得API版本變得強制性，不要發佈無版本的API。
/api/v1/blog 面向擴展開放，面向修改關閉，在這裏v1就是指的版本
注：上述筆記來自於筆者平時看視頻整理所得，如有侵權還請聯繫刪除