那些年，我們一起誤解過的REST

歡迎大家前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由sammyshen 發表於雲+社區專欄

最近幾年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

對推導過程感興趣的朋友可以參考Roy Fielding的論文。

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：用於查詢資源。
• POST：用於創建資源。POST方法創建資源的URI由服務器決定，如：POST <http://www.example.com/Fielding/books>，創建了一個book資源，資源的URI爲<http://www.example.com/Fielding/books/:id>，其中:id爲服務器生成的ID，可能是自增ID或哈希值等等。而POST <http://www.example.com/Fielding/books/123>，則是在ID爲123的book資源下創建一個某類別資源，如書的評論等，評論的URI也會包含一個服務器生成的ID。
• 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的一個可選的架構約束條件。

問答
Java中的REST
相關閱讀
體驗Django REST framework，解讀REST架構風格
我是怎麼一步步用go找出壓測性能瓶頸
當 MySQL 連接池遇上事務（一）：神祕的幽靈鎖
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！