一直想寫關於REST風格的文字，因為我所接觸的程式設計師朋友，不管是前輩還是後輩，都對其有很大的誤解。原因可能是最初的老師傅們把節奏帶偏了吧。

之前我也一直搞不懂rest，和大多數人一樣，以為 請求地址 中，只有沒有 ？、沒有類似的 .do  .action就是所謂的rest風格。直到道了一家網際網路公司，才弄明白，之前的想法簡直是對作者的侮辱啊。在整理文章資料的時候，發現瞭如下文章，和我想表達的完全相符，而且比我整理的更加細緻，完整。顧直接轉發了，具體作者不知道是誰。

本文是轉載，作者未知，內容如下：

最近幾年REST API越來越流行，特別是隨著微服務的概念被廣泛接受和應用，很多Web Service都使用了REST API。

REST是HTTP規範主要編寫者之一的Roy Fielding提出的，全稱是Representational State Transfer，中文可以翻譯為表述性狀態轉移。它不是一種架構，而是一種架構風格。REST提出了一組架構約束條件和原則，任何滿足REST約束條件和原則的架構，都稱為RESTful架構。

REST雖然流行，但是從業界應用的效果看，良莠不齊。很多系統只是號稱是REST API，實際上並沒有滿足REST的架構約束條件。這些系統按照自己的理解，採用了類似REST API的部分形式（如用GET/POST/PUT/DELETE進行CURD），但更多的是隨意設計，搞出了REST-RPC式，甚至是RPC式的API。這樣的API，不僅沒體現出REST API的優勢，反而搞成“四不像”，增加了開發維護成本。

如何理解REST

要規範使用RESTful架構，首先要理解什麼是REST。我們可以通過分別理解“表述”“狀態轉移”來理解REST。

1) 表述

表述指的是資源的表示。RESTful架構是基於資源的架構（ROA, Resource-Oriented Architecture），在ROA中，處理的物件都是資源。任何需要被引用的物件，都是資源。資源表現為某個具體的URI。

所謂表述，指的是資源的某種形式的表示，這個表示不一定是所有資訊，可以只是關注的部分資訊。並且，同一個資源，可以有多個表述。例如，對於一個景點，可以用jpeg照片來表示，也可以用包含位置、介紹等資訊的json或xml格式來分別表示。

在REST中，客戶端與伺服器之間的通訊，傳輸的都是資源的表述。

2) 狀態轉移

狀態其實應該分為應用狀態和資源狀態。

應用狀態由客戶端儲存維護，例如會話狀態等。客戶端通過REST API返回的表述，以及表述中的URI，進行客戶端應用狀態的轉移。

但REST更強調的是資源狀態。資源狀態儲存在伺服器端，客戶端通過REST API，指定請求方法、資源路徑和資源表述（可以包含應用狀態），對資源的狀態進行增刪查改。通過增刪查改，引起資源狀態的改變，稱為狀態轉移。

3) 結論

結合上面兩點，客戶端通過REST API對伺服器端的資源進行增刪查改，引起資源的狀態轉移。而這種轉移是體現在表述上的，所以稱為表述性狀態轉移。

怎樣才算是符合REST架構風格

Roy Fielding在他的論文裡通過對一個空架構不斷追加約束條件，從而推匯出了REST架構風格。因此，要想符合REST架構風格，則需要滿足對應的約束條件。

image.png

REST的約束條件有：

1. 統一介面
2. 無狀態
3. 快取
4. 客戶端-伺服器
5. 分層系統
6. 按需程式碼（可選）

其中，統一介面是最直觀、也是應用中偏差最大的地方，下面會重點講解。其餘各約束條件則簡單講解。

1. 統一介面

統一介面其實體現在多個方面：

• 資源URI
• 請求引數
• 請求方法
• 返回碼
• 返回內容
• ……

1) 資源URI

RESTful架構是基於資源的架構，所操作的一切物件都是資源。因此，需要明確地定位一個資源，而URI技術正好滿足這個需求，所以REST中通過URI來定位資源。

資源是一個物件，所以URI中一般只能包含名詞（一般是複數），不應該包含動詞。當需要定位具體的資源時，URI中一般包含資源的唯一ID。例如：

// 滿足REST架構風格的URI
http://www.example.com/books    // 所有書籍的資源集合
http://www.example.com/books/123    // ID為123的書籍資源

// 不滿足REST架構風格的URI
http://www.example.com/books/query
http://www.example.com/buy

2) 請求引數

因為REST需要通過URI來唯一定位某個（或某種）資源，所以查詢資源時，各種資源ID一般是放在URI裡面，而不是放在請求引數裡面。請求引數中一般放過濾條件分頁資訊等欄位。例如：

// 滿足REST架構風格的URI
http://www.example.com/books/123    // ID為123的書籍資源
http://www.example.com/Fielding/books?page=1&per_page=10    // 作者為Fielding的前10本書籍資源集合

// 不滿足REST架構風格的URI
http://www.example.com/books?id=123
http://www.example.com/books?author=Fielding

3) 請求方法

REST約定用GET/POST/PUT/DELETE等請求方法來進行CURD操作。但是否使用了GET/POST/PUT/DELETE，並不能作為評判一個系統是否符合REST架構風格的標準。例如，有些系統所有介面都使用GET和POST方法，如果該系統只提供查詢和建立操作，那麼可能是符合REST架構風格的；但如果該系統還提供修改、刪除操作，則該系統不符合REST架構風格。

有些人認為GET/POST/PUT/DELETE跟CURD是一對一的關係，其實不是。

具體的說，各請求方法如下：

• GET：用於查詢資源。
• PUT：用於建立或修改資源。PUT方法建立資源的URI由客戶端決定，如：PUT http://www.example.com/Fielding/books/123，當ID為123的book資源存在時，將進行修改操作；否則進行建立操作。
• DELETE：用於刪除資源。

另外，還有其他較少用的請求方法，需要注意的是可能部分瀏覽器不支援。

• HEAD：用於獲取資源的元資訊。HEAD方法與GET方法類似，都可以查詢資源的元資訊（放在HTTP Response的Header），但不會返回資源的表述。例如用於判斷資源是否存在。
• PATCH：用於修改資源。與PUT方法不同的是，PATCH方法只傳輸改動的部分資源表述，而PUT方法需要傳輸完整的資源表述。

4) 返回碼

REST使用HTTP返回碼來表示請求的結果。如果使用規範的REST API，那麼根據HTTP返回碼就能確定很多資訊。常見的HTTP返回碼如下：

• 200（OK）：表示請求成功。
• 201（Created）：表示資源建立成功。
• 204（No content）：表示資源為空。
• 301（Moved Permanently）：表示資源的URI已永久性更改，需要在響應內容中獲取新的URI。
• 302（Moved Temporarily）：表示資源的URI已臨時性更改，需要在響應內容中獲取新的URI。
• 400（Bad Request）：表示請求有問題，如引數錯誤等。
• 403（Forbidden）：表示鑑權不通過，沒有許可權訪問該資源。
• 404（Not Found）：表示資源不存在。
• 405（Method Not Allowed）：表示該資源不支援當前的請求方法。
• 409（Conflict）：表示當前請求的某前置條件不符合。
• 500（Internal Server Error）：通用內部錯誤。
• 502（Bad Gateway）：閘道器錯誤，從上游伺服器收到無效響應。
• 504（Gateway Timeout）：閘道器超時，在預期時間內沒有收到上游伺服器的響應。
• ……

還有其他HTTP返回碼，可以參考HTTP標準。

只要使用了規範的REST架構風格，那麼就可以根據HTTP的標準，做出明確的相應處理，無需另外製定私有協議了。既減少了私有協議的相容性問題，又能作為標準適用於所有的RESTful架構。

5) 返回內容

REST API的返回內容應該是資源的表述。

前面說過，同一個資源可以有多種不同格式的表述，如json格式和xml格式，所以返回內容應該是自描述的。也就是說，在HTTP響應的Header中，必須包含Content-type屬性，如application/json、application/xml、text/html等。

另外，REST是“可程式設計”的Web服務，也就是說，程式可以根據REST API的返回內容，進行下一步的操作。例如，查詢author資源，下一步可能是要查詢該作者著作的book資源。所以，如果author資源的表述中包含了該作者著作book資源的URI，則客戶端可以進行相應的操作。又如，查詢某個地圖資源，地圖資源的表述中如果包含了各方向的相鄰地圖資源，則當客戶端的滑鼠移到螢幕邊緣時，就可以獲取到該方向上的地圖資源了；或者地圖資源的表述中包含景點、餐館等資源URI，則可以進行相應的操作。

在表述中包含其他資源的URI實現了連通性。連通性可以作為客戶端應用狀態的狀態引擎，引導客戶端進行下一步的操作，帶來了極大的便利。

6) 其他

統一介面還有其他方面的原則，本文就不細講了，感興趣的朋友可以閱讀Fielding的論文。

2. 無狀態

無狀態約束條件是指兩次請求之間不存在依賴關係，每一次請求都包含完整的狀態資訊。這裡指的狀態是指客戶端與伺服器之間通訊互動的狀態，與資源狀態無關。

舉個有狀態的例子，為了查工資，需要先登入系統（第一次請求），再輸入查詢密碼（第二次請求）。如果前面兩次請求都通過了，那麼呼叫查詢介面則可以查詢到工資；否則呼叫查詢介面則報未鑑權的錯誤。查詢工資介面的返回結果與前面兩次請求的狀態是關聯的，所以是有狀態的服務。

而無狀態的服務，則直接呼叫查詢工資介面，在請求中（一般在Header中）帶有鑑權資訊，若鑑權通過則可查詢到工資，鑑權不通過則報錯。該請求不依賴於任何前置請求，稱為無狀態。

REST使用無狀態約束條件，確保了請求的獨立性和簡單性，減少了很多跨請求的狀態維護成本。當然，帶來的代價是每次請求可能需要傳輸冗餘的資訊。

3. 快取

快取約束條件主要是用於改善網路的效率。快取約束條件要求一個請求的響應中的資料被隱式地或顯式地標記為可快取的或不可快取的。如果響應是可快取的，那麼客戶端快取就可以為以後的相同請求重用這個響應的資料，減少了網路互動，提高了效率、可伸縮性和使用者感知的效能。

4. 客戶端-伺服器

這個約束條件主要是分離使用者介面和資料儲存，一方面改善使用者介面跨平臺的可移植性，另一方面簡化伺服器元件，改善系統的可伸縮性。

5. 分層系統

分層系統架構約束條件將架構分為若干層，劃定每一層的邊界，從而降低每一層設計的複雜度。同時，通過分層，可以抽象底層的異構性，給上層提供統一的介面，簡化上層的邏輯。

6. 按需程式碼

按需程式碼約束條件是指某些場景下，客戶端不清楚資源的處理方法，通過向伺服器請求相應的處理程式碼來執行。這樣可以簡化客戶端開發，允許部署後下載功能程式碼來改善系統的可擴充套件性。但是，因為傳輸的是代買，降低了可見性，所以是REST的一個可選的架構約束條件。