REST首次出現在 2000 年 Roy Fielding 的博士論文中的一種軟件架構風格。可以降低開發的複雜性,提高系統的可伸縮性。
一、資源
REST中可以命名的任何信息都可以是資源,如user、order等,通常表示Web服務中要操作的一個實體。一個資源具有統一的URI,通過URI能夠標識並訪問資源。
二、REST約束
REST定義了6個約束,符合這些約束的web服務才能成爲REST風格的服務。
1.客戶端—服務器
服務端與客戶端獨立實現並獨立開發,只要接口不改變即可。提高跨多個平臺的用戶接口的可移植性並提高可伸縮性。
2.統一接口
系統中的多個組件都依賴於統一接口,包含4個子約束:
- 資源的標識
資源通過URL區分,當訪問一個URL時,能夠獲取該資源或對它執行相應的操作。 - 通過表述操作資源
客戶端請求資源時,可以指定期望的格式,服務器返回響應時,響應包含了指定格式的資源。訪問同一個資源的不同格式無須修改資源的標識符,客戶端也可以通過資源的表述對資源進行操作。 - 自描述消息
客戶端和服務器之間傳遞的消息都應包含足夠的信息(如資源表述的格式和內容長度,甚至相關的其他操作信息)。 - 超媒體作爲應用程序狀態的引擎(HATEOAS)
服務器返回的資源表述中包含與之相關的鏈接,這些鏈接能夠對資源執行其他操作。
3.分層系統
服務端和客戶端不知道網絡中介(代理或網關等)的存在,增強安全、負載均衡和響應緩存等。
4.緩存
客戶端和網絡中介都可以緩存服務器返回的響應,以便於減少數據獲取延遲和服務器的請求次數,提高系統性能。
5.無狀態
服務器不會記錄或存儲客戶端的狀態信息。從客戶端到服務器的每個請求都必須包含理解請求所需的所有信息,並且不能利用服務器上任何存儲的上下文。
6.按需編碼(可選)
允許服務器臨時向客戶端返回可執行的程序代碼用於客戶端拓展和自定義功能,簡化客戶端。
三、設計原則
- 使用名詞的複數表示資源集合 api/users
- 使用斜線“/”表示資源間的層次關係 api/users/1/orders
- 對資源進行CRUD的操作名稱不應出現在URL中,使用HTTP方法進行區分
- 查詢字符串可以用來篩選、搜索和分頁等操作
- URI使用小寫字母,使用“-”增加可讀性,避免使用下劃線,結尾不應含有斜線“/”