1.簡介
2000年Roy Fielding博士在其博士論文中提出REST（Representational State Transfer）風格的軟件架構模式后，REST就基本上迅速取代了復雜而笨重的SOAP，成為Web API的標准了。
RESTful作為目前最流行的 API 設計規范，一定有着它獨有的魅力：強大、簡介、易上手。
2.URL設計
2.1 數據的安全保障
-
url鏈接一般都采用https協議進行傳輸
注：采用https協議，可以提高數據交互過程中的安全性
2.2 接口特征表現
-
用api關鍵字標識接口url：
注：看到api字眼，就代表該請求url鏈接是完成前后台數據交互的
2.3 多數據版本共存
-
在url鏈接中標識數據版本
注：url鏈接中的v1、v2就是不同數據版本的體現（只有在一種數據資源有多版本情況下）
2.4 數據即是資源
-
接口一般都是完成前后台數據的交互，交互的數據我們稱之為資源
注：一般提倡用資源的復數形式，在url鏈接中獎勵不要出現操作資源的動詞，錯誤示范：https://api.baidu.com/delete-user
-
特殊的接口可以出現動詞，因為這些接口一般沒有一個明確的資源，或是動詞就是接口的核心含義
2.5 資源操作由請求方式決定
- 操作資源一般都會涉及到增刪改查，我們提供請求方式來標識增刪改查動作
- https://api.baidu.com/books - get請求：獲取所有書
- https://api.baidu.com/books/1 - get請求：獲取主鍵為1的書
- https://api.baidu.com/books - post請求：新增一本書書
- https://api.baidu.com/books/1 - put請求：整體修改主鍵為1的書
- https://api.baidu.com/books/1 - patch請求：局部修改主鍵為1的書
- https://api.baidu.com/books/1 - delete請求：刪除主鍵為1的書
3.響應狀態碼
3.1 正常響應
- 響應狀態碼2xx
- 200：常規請求
- 201：創建成功
3.2 重定向響應
- 響應狀態碼3xx
- 301：永久重定向
- 302：暫時重定向
3.3 客戶端異常
- 響應狀態碼4xx
- 403：請求無權限
- 404：請求路徑不存在
- 405：請求方法不存在
3.4 服務器異常
- 響應狀態碼5xx
- 500：服務器異常
4.響應結果
4.1 響應數據要有狀態碼、狀態信息以及數據本身
{
"status": 0,
"msg": "ok",
"results":[
{
"name":"肯德基(羅餐廳)",
"location":{
"lat":31.415354,
"lng":121.357339
},
"address":"月羅路2380號",
"province":"上海市",
"city":"上海市",
"area":"寶山區",
"street_id":"339ed41ae1d6dc320a5cb37c",
"telephone":"(021)56761006",
"detail":1,
"uid":"339ed41ae1d6dc320a5cb37c"
}
...
]
}
4.2 需要url請求的資源需要訪問資源的請求鏈接
{
"status": 0,
"msg": "ok",
"results":[
{
"name":"肯德基(羅餐廳)",
"img": "https://image.baidu.com/kfc/001.png"
}
...
]
}