RESTful API
-
產生背景
- 前后端分離后,前端調用指定API獲取到后端的數據,再展示出來,而隨著前端設備的多樣性(手機,平板,桌面電腦,其他專用設備等等),需要一種統一的機制,方便前后端通信,所以RESTful就是這樣一種API設計理念,可以通過一套統一的接口為web,ios等提供服務。
-
REST
- REST 即:Representational State Transfer的縮寫,“表現層狀態轉化”。
- 理解:
- 1.url定位資源
- 2.客戶端和服務端之間傳遞這種資源的表現層
- 3.客戶端通過HTTP動詞(get,post,delete,put,patch)對服務端資源進行操作,實現變現層狀態轉化
-
RESTful 六大原則
-
C-S架構
- 數據存儲在Server端,Client端只需要使用。前后端分離使得Client端的代碼可移植性增強,Server端擴展性增強,兩端單獨開發,互相不干擾。
-
無狀態
- http請求本身就是無狀態的,基于C-S架構,客戶端每一次請求都要帶著充分的信息讓服務端識別。服務端根據請求的參數,無需保存客戶端的狀態,將響應正確的返回給客戶端,大大提高了效率和性能。
- 缺點就是客戶端的每一次請求都需要帶上相同重復的信息表明自己的身份和狀態,會造成傳輸的冗雜,但這些對于性能和使用來說,可以忽略不計。
-
統一的接口
- REST架構的核心內容,統一的接口對于RESTful服務來說非常必要,前端只需要關注接口,接口的可讀性增加,使用人員方便調用
- REST接口約束為:
- 資源識別:通過url標識你要操作的資源
- 請求動作:通過請求動作(post,put,get等)標識執行的操作
- 響應信息:通過返回的狀態碼來表示這次請求的執行結果
-
一致的數據格式
服務端返回的數據要么是XML,要么是json,要么是狀態碼
比如請求一條微博信息,服務端響應信息應該包含這個微博相關的其他URL,客戶端就可以進一步利用這些URL發起請求獲取感興趣的信息,就像分頁,第一頁里可以獲取下一頁的URL就是這個原理
下面以返回數據json格式為例簡單講一下數據格式
-
返回數據通常含有一些字段:
code
-----HTTP響應狀態碼,status
------包含文本“success”(其他) |'fail ‘ (狀態碼5××) |'error'(狀態碼4××)message
-----狀態值為’fail‘和’error‘時生效,顯示錯誤信息data
-----包含響應的數據,狀態值為fail或者error,data僅包含錯誤原因或者異常名稱或者null也可以。比如下面就是一個響應成功的json格式
{ "code": 200, "message": "success", "data": { "userName": "123456", "age": 16, "address": "beijing" } }
-
可緩存
- 在萬維網上,客戶端是可以緩存頁面的響應內容,因此響應都應該顯式或隱示的定義為可緩存,如果不可以緩存也要避免客戶端拿舊數據或者臟數據來響應,緩存得當可以減少客戶端和服務端的交互,進一步的優化性能。
-
按需編碼,可定制代碼
- 服務端可選擇臨時給客戶端下發一些功能代碼讓客戶端來執行,從而定制和擴展客戶端的某些功能。比如服務端可以返回一些 Javascript 代碼讓客戶端執行,去實現某些特定的功能。提示:REST架構中的設計準則中,只有按需編碼為可選項。如果某個服務違反了其他任意一項準則,嚴格意思上不能稱之為RESTful風格。
-
-
HTTP動詞
- GET:從服務器取出資源
- POST:在服務器新建一個資源
- PUT: 在服務器更新資源(客戶端提供改變后的完整資源)
- PATCH:在服務器更新資源(客戶端提供改變的屬性)
- DELETE:從服務器刪除資源
-
HTTP狀態碼
- 1××:不常用,表示請求未成功
- 2××:成功
- 3××:重定向,原有文件永久搬走或者臨時出走
- 4××: 客戶端的請求可能出錯了
- 5××: 服務端內部出錯了