目錄
Rest 風格的誕生
在 HTTP 協議發展的過程中，提出了很多的規則，但是這些規則有些煩瑣，於是又提出了一種風格約定，它便是 Rest 風格。實際上嚴格地說它不是一種標準，而是一種風格。在現今互聯網的世界中這種風格己經被廣泛使用起來了 。 尤其是現今流行的微服務中，這樣的風格甚至被推薦爲各個微服務系統之間用於交互的方式。在這樣的風格下對於簡易參數則儘量通過網址進行傳遞。
Rest 風格到底是什麼
REST 按其英文名稱（Representational State Transfer) 可翻譯爲表現層狀態轉換。 首先需要有資源才能表現， 所以第一個名詞是“資源”。 有了資源也要根據需要以合適的形式表現資源，這就是第二個名詞“表現層”。最後是資源可以被新增、修改、刪除等，也就是第三個名詞“狀態轉換”。這就是 REST 風格的三個主要的名詞。
Rest 名詞解釋
- 資源
它可以是系統權限用戶、角色和菜單等，也可以是一些媒體類型， 如文本、圖片、歌曲，總之它就是一個具體存在的對象。 可以用一個 URI (統一資源定位符）指向它， 每個資源對應一個特定的URI。要獲取這個資源， 訪問它的URI即可， 而在 REST 中每一個資源都會對應一個獨一無二的 URI。 - 表現層
有了資源還需要確定如何表現這個資源。可以使用 JSON、 XML 或者其他的形式表現出來比如圖片等，但是在現今的互聯網開發中， JSON 己經是一種最常用的表現形式。 - 狀態轉換
現實中資源並不是一成不變的， 它是一個變化的過程， 一個資源可以經歷創建 (create）、 訪問 （visit）、 修改（update） 和刪除（delete）的過程。 對於 HTTP 協議而言，它是一個沒有狀態的協議，這也意味着對於資源的狀態變化就只能在服務器端保存和變化，不過好在 HTTP 中卻存在多種動作來對應這些變化。
REST 風格架構的特點
- 服務器存在一系列的資源，每一個資源通過單獨唯一的 URI進行標識
- 客戶端和服務器之間可以相互傳遞資源，而資源會以某種表現層得以展示
- 客戶端通過 HTTP 協議所定義的動作對資源進行操作，以實現資源的狀態轉換
HTTP 的動作
對於資源而言，它存在創建（create）、修改 （update）、訪問 （visit） 和刪除 （delete） 的狀態轉換， 對應於 HTTP 行爲中的 5 種動作
- GET (VISIT）： 訪問服務器資源（一個或者多個資源）。
- POST (CREATE）： 提交服務器資源信息， 用來創建新的資源。
- PUT (UPDATE）：修改服務器己經存在的資源，使用 PUT 時需要把資源的所有屬性一併提交。
- PATCH (UPDATE）： 修改服務器已經存在的資源，使用 PATCH 時只需要將部分資源屬性提交。 目前來說這個動作並不常用也不普及， 有些 Java 類還不能完全支持它， 所以在現實中使用它需要慎重。
- DELETE (DELETE）： 從服務器將資源刪除。
其中 POST 動作對應創建資源， PUT 和 PATCH 對應更新資 源， GET 請求對應訪問資源， DELETE 對應刪除資源。 對於 HTTP 協議， 還有另外兩種不常用的動作行爲
- HEAD： 獲取資源的元數據。
- OPTIONS： 提供資源可供客戶端修改的屬性信息。
使用 Spring MVC 開發 REST 風格項目
Spring 對 REST 風格的支持是基於 SpringMVC 設計基礎上的， 在 Spring 4.3 之前只能使用＠RequestMapping 設計 URI，在 Spring 4.3 之後則有更多的註解引入使得 REST 風格的開發更爲便捷。
Spring MVC 整合 REST
- @GetMapping：對應 HTTP 的 GET 請求，獲取資源。
- @PostMapping：對應 HTTP 的 POST 請求，創建資源。
- @PutMapping： 對應 HTTP 的 PUT 請求，提交所有資源屬性以修改資源。
- @PatchMapping： 對應 HTTP 的 PATCH 請求，提交資源部分修改的屬性。
- @DeleteMapping： 對應 HTTP 的 DELETE 請求，刪除服務器端的資源。
處理 HTTP 狀態碼、異常和晌應頭
當發生資源找不到或者處理邏輯發生異常時， 需要考慮的是返回給客戶端的 HTTP 狀態碼和錯誤消息的問題。 爲了簡化這些開發 ， Spring 提供了實體封裝類 ResponseEntity 和註解＠ResponseStatus。 ResponseEntity 可以有效封裝錯誤消息和狀態碼，通過 @ResponseStatus 可以配置指定的響應碼給客戶端。