10.REST
REST原則 是 Roy Thomas Fielding 在 2000年博士論文中提出的。他對互聯網軟件架構原則命名爲 REST [表現層狀態轉化]。如果一個架構符合 REST原則，就稱它爲 RESTful 架構。
關於 RESTful 架構，最好的方法是去理解 Representational State Transfer 的意義。
-
資源 [Resources]
REST 的名稱 “表現層狀態轉化”，其實省略掉了主語。 表現層 其實指的是 資源
所謂 資源，就是網絡上一個實體(具體信息)，可以是文本、圖片、音視頻、服務等。標識資源實體的識別符爲：
URI。 每種資源均對應一個特定的URI，要獲取這個資源，訪問它的URI即可。 -
表現層 [Representation]
資源是一種信息實體，他可以用多種表現形式。表現層是資源具體呈現的形式。比如：文本可以用 txt 、HTML、XML、JSON、二進制格式進行表現。URI只代表信息實體的位置，無關乎表現形式。 信息實體的表現形式應該在 HTTP 請求頭部信息中採用 Accept 和 Content-Type 字段指定。 -
狀態轉換 [State Transfer]
用戶通過瀏覽器訪問網站，就代表了 [客戶端] 和 [服務端] 的一個互動過程。在這個過程中，勢必涉及到數據和狀態的變化。 HTTP協議是一個無狀態的互聯網通信協議，這意味着所有的狀態信息均保存在 [服務端]。因此，如果 [客戶端] 想要操作 [服務端] ，必須通過某種手段，讓 [服務端] 發生
狀態變化。而這種轉化是建立在 表現層 之上的。因此稱爲： 資源表現層狀態轉化。 -
HTTP 協議裏存在七個常用表示操作方式的動詞
- GET [獲取資源]
- POST [新建資源、更新資源]
- PUT [更新資源，客戶端需要提供完整的資源屬性]
- DELETE [刪除資源，在業務系統中刪除並不是指的物理刪除，而是邏輯刪除。資源通常仍然在數據庫中，只是狀態設置爲刪除狀態]
- PATCH [更新資源的部分屬性]
- HEAD [類似 GET，但僅僅有 HTTP 頭信息，頭信息包含了需要查找的信息]
- OPTIONS [用於獲取 URI 所支持的方法，響應信息會在 HTTP 頭中包含一個名爲
Allow的key，value是所支持的方法]
-
Web框架中 REST風格架構要求：
-
使用
api作爲 web 上下文，比如： -
增加版本標識，比如：
-
標識資源，將資源名稱放到URL中，比如：
-
REST 中的 HTTP Method，採用上述的操作動詞舉例：
- POST – http://192.168.0.1/api/v1.1/system/user [增加系統用戶]
- GET – http://192.168.0.1/api/v1.1/system/user/7 [查詢ID爲7的用戶]
- DELETE – http://192.168.0.1/api/v1.1/system/user/17 [刪除ID爲17的用戶]
-
REST 中的 HTTP Status
[服務端] 向 [客戶端] 返回 HTTP Status 以表示操作是否成功，常用舉例如下：
- 200 [OK 用戶請求成功，數據成功返回]
- 400 [錯誤的請求，請求參數匹配錯誤]
- 404 [NOT Found 用戶發出的請求針對的資源不存在]
- 405 [用來訪問本頁面的 HTTP Method 不被允許]
- 406 [表示無法使用請求的內容特性來響應請求的資源]
- 500 [服務器內部錯誤，無法完成請求]
-
-
@RestController
Spring Boot 應用引入基礎web開發相關依賴，即可自動支持REST。
爲了簡化開發，針對REST架構風格，會有一些便捷註解進行聲明。(原生註解也可實現REST，這裏只是爲了簡化開發) 比如：
@RestController=@Controller+@ResponseBody可以使用請求模擬工具：Postman，進行請求的模擬測試。
-
Swagger UI [Restful風格接口的文檔在線自動生成和測試的框架]
Swagger是個前後端協作的利器，解析代碼裏的註解生成JSON文件，通過Swagger UI生成網頁版的接口文檔，可以在上面做簡單的接口調試。詳情可以查看我博客之前提到的Spring Boot整合Swagger的文章。鏈接如下：