RESTful 架構

一、 起源

REST這個詞是Roy Thomas Fielding在他2000年的博士論文中提出的。

Fielding是一個非常重要的人，他是HTTP協議（1.0版和1.1版）的主要設計者、Apache伺服器軟體的作者之一、Apache基金會的第一任主席。

This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. 
Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. 
Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. 
My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. 
When given a name, a coordinated set of architectural constraints becomes an architectural style.

"本文研究電腦科學兩大前沿--軟體和網路--的交叉點。
長期以來，軟體研究主要關注軟體設計的分類、設計方法的演化，很少客觀地評估不同的設計選擇對系統行為的影響。
而相反地，網路研究主要關注系統之間通訊行為的細節、如何改進特定通訊機制的表現，常常忽視了一個事實，那就是改變應用程式的互動風格比改變互動協議，對整體表現有更大的影響。
我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、效能好、適宜通訊的架構。"

如何評估web架構？

論文的目的之一是為選擇或建立應用程式的架構時提供設計指導，為此需要一個評估機制，架構設計很難客觀的進行評估和比較，像藝術品一樣，架構通常為完整的作品呈現。但我們可以通過一組協調的架構約束(SOAP或REST)看做一種樣式的應用。當他們的約束不衝突時，可以將樣式組合起來形成混合樣式。我們在這些樣式中總結出屬性，然後根據屬性的權重值來進行評估。但不是權重值高或低就一定好或壞，應當在各個屬性中取得可接受的均衡。

評估web架構的關鍵屬性：

1. 效能 Performance：影響高可用的關鍵因素

   1. 網路效能 Network Performance. 用於描述通訊的某些屬性

      1. Throughput 吞吐量：小於等於頻寬 bandwidth

      2. Overhead 開銷：首次開銷，每次開銷

         樣式通過影響每個使用者操作的互動次數和資料元素的粒度來影響網路效能

   2. 使用者感知的效能 User-perceived Performance

      1. Latency 延遲：發起請求到接收到響應的時間

      2. Completion 完成時間：完成一個應用動作所花費的時間

         常見的提高使用者感知效能的做法如：逐步載入頁面，大檔案壓縮等

   3. 網路效率 Network Efficiency

      1. 重用快取、減少互動次數、傳輸距離更近CDN等

2. 可伸縮性 Scalability：支援部署可以互相互動的大量元件

3. 簡單性 Simplicity：易理解、易實現、易驗證

4. 可修改性 Modifiability：對系統作出修改的難易程度，由可進化性、可定製性、可擴充套件性、可配置性、可重用性構成

   1. 可進化性 Evolvability：一個元件獨立升級而不影響其他元件
   2. 可擴充套件性 Extensibility ：向系統新增功能，而不會影響到系統的其他部分
   3. 可定製性 Customizability ：臨時性、定製性地更改某一要素來提供服務， 不對常規客戶產生影響
   4. 可配置性 Configurability ：應用部署後可通過修改配置提供新的功能
   5. 可重用性 Reusabilit ：元件可以不做修改在其他應用在使用

5. 可見性 Visiable：對兩個元件間的互動進行監視或者仲裁的能力。如快取、分層設計等

6. 可移植性 Portability：在不同的環境下執行的能力

7. 可靠性 Reliability：出現部分故障時，對整體影響的程度

視覺化圖表：-為負面影響，+為正面影響，±表示取決於問題域的某些方面

資料流風格 Data-flow Styles

優點：簡單性、可進化性、可擴充套件性、可配置性、可重用性

管道和過濾器 pipe-line filter（PF）

例如：apache cocoon

PF支援重用：只要兩個過濾器就它們之間正在傳輸的資料達成一致（可重用性）

PF系統可以輕鬆維護和增強：可以將新過濾器新增到現有系統中（可擴充套件性）

支援併發執行（使用者感知的效能）

統一管道和過濾器 Uniform Pipe filter（UPF）

特點是：所有過濾器必須具有相同介面的約束

這樣做提高了可見性和簡單性和可移植性，但因為需要將資料轉換為指定的格式，則可能降低網路效能。

複製風格 Replication Styles

優點：使用者可察覺的效能、可伸縮性，網路效率、可靠性也可以得到提升

複製儲存庫 Replicated Repository（RR）

例如：CVS,mysql

通過讓多個程式提供相同的服務（可使用nginx反向代理）來提高資料的可訪問性和服務的可伸縮性.

可伸縮性和可靠性更好,保持一致性是主要問題。

快取（$）

網路效率更高，可伸縮性和可靠性更好。

分層風格 Hierarchical

優點：簡單性、可進化性、可伸縮性、可重用性

客戶端-伺服器 client-service（CS）

可伸縮性 聯結器所使用的機制經常引用，例如RPC或者MQ。

分層系統 Layered System（LS）和分層客戶端伺服器 Layered Client-Server（LCS）

分層系統是按層次結構組織的，每一層都為其上一層提供服務，並使用其下一層的服務，從而減少了跨多層的耦合，提高了可擴充套件性和可重用性。

客戶端無狀態伺服器 Client-Stateless-Server（CSS）

基於CS，其附加約束是伺服器元件上不允許有會話狀態。

從客戶端到伺服器的每個請求都必須包含理解該請求所需的所有資訊，
並且不能利用伺服器上儲存的任何上下文。
會話狀態完全保留在客戶端上。

提升了可見性、可伸縮性、可靠性，但重複資料導致降低網路效能.

這些限制改善了可見性，可靠性和可伸縮性的屬性。
可見性得到了改善，因為監視系統不必為了確定請求的全部性質而超出單個請求資料。
可靠性得到改善，因為它簡化了從部分故障中恢復的任務,可伸縮性得到了改善，因為不必在請求之間儲存狀態，這使得伺服器元件可以快速釋放資源並進一步簡化實現。
它可能會通過增加在一系列請求中傳送的重複資料（每次互動開銷）來降低網路效能.
因為該資料無法在共享上下文中留在伺服器上。

3.4.4客戶端快取無狀態伺服器（C $ SS）

提升效能

快取充當客戶端和伺服器之間的中介，在其中，對先前請求的響應（如果被認為是可快取的）可以被重用，
新增快取元件的優勢在於它們有潛力部分或完全消除某些互動，從而提高效率和使用者感知的效能。

分層客戶端快取無狀態伺服器（LC $ SS）

在C $ SS的基礎上新增代理或閘道器。

變體CS分層風格

遠端回話 Remote Session, RS

- CS 變體，伺服器儲存Application state 應用狀態（比如FTP，需要知道上次使用者訪問所在的目錄）
- 可伸縮性、可見性差

遠端資料訪問 Remote Data Access，RDA

- CS變體，Application state應用狀態同時分佈在客戶端和伺服器
- 巨大的資料及有可能通過迭代而減少
- 簡單性、可伸縮性差

移動程式碼樣式 Mobile Code Styles

優點：網路效能，網路效率，可靠性，擴充套件性，可配置性

虛擬機器 Virtual Machine， VM

• 分離指令與實現

遠端求值 Remote Evaluation， REV

• 基於 CS 的 VM，將程式碼傳送至伺服器執行

- 按需程式碼 Code on Demand， COD

• 伺服器在響應中發回處理程式碼，在客戶端執行

• 優秀的可擴充套件性和可配置性，提升使用者可察覺效能和網路效率

分層、按需程式碼、快取、無狀態、客戶端伺服器

• Layered-Code-on-Demand-Client-Cache-Stateless-Server， LCODC$SS

• LC$SS+COD

移動代理 Mobile Agent， MA

• 相當於 REV+COD

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-3ws8GouV-1601014499875)(/Users/cuijie/Library/Application Support/typora-user-images/image-20200922110205163.png)]

點對點風格 Peer-to-Peer Styles

優點：可進化型，可擴充套件性，可配置型，可重用性

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-Pg4XMxs9-1601014499876)(/Users/cuijie/Library/Application Support/typora-user-images/image-20200922110252376.png)]

Event-based Integration ，EBI：

• 基於事件整合系統，如由類似 Kafka 這樣的訊息系統 + 分發訂閱來消除耦合
• 優秀的可重用性、可擴充套件性、可進化性
• 缺乏可理解性
• 由於訊息廣播等因素造成的訊息風暴，可伸縮性差

Chiron-2,C2

參見論文《A Component- and Message-Based Architectural Style for GUI Software》 • 相當於 EBI+LCS，控制了訊息的方向

Distributed Objects ，DO

• 元件結對互動

Brokered Distributed Objects ，BDO

• 引入名字解析元件來簡化 DO，例如 CORBA

風格演化

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-p4E27edu-1601014499877)(/Users/cuijie/Library/Application Support/typora-user-images/image-20200922110427806.png)]

原點 通過新增分離約束 形成 CS樣式 獲得了 (可移植性、可伸縮性),分離允許元件獨立發展

形成CS之後，允許服務端叢集化 也就形成了RR

繼續新增無狀態約束 形成CSS樣式 獲得了（可見性、可靠性、可伸縮性）,但降低了網路效能，因為會傳送重複資料。

以便從客戶端到客戶端的每個請求伺服器必須包含理解請求所必需的所有資訊，並且不能利用伺服器上儲存的任何上下文。
因此，會話狀態完全保留在客戶端上。

繼續新增快取約束 形成了 C$SS樣式 獲得了（可伸縮性、使用者感知的效能）

繼續新增統一介面約束

繼續新增分層的約束 形成了LC$SS樣式 加強了（可伸縮性、簡單性、可進化型、可移植性）

增加了資料處理的開銷和延遲，從而降低了使用者感知的效能,分層系統和統一的介面約束的組合產生了類似於統一的管道和過濾器樣式的架構屬性

繼續新增按需編碼約束 形成了LCODC$SS.

REST允許通過以applet或指令碼的形式下載並執行程式碼來擴充套件客戶端功能。
通過減少預先實現的功能數量，簡化了客戶端。
部署後允許下載功能可以提高系統的可擴充套件性。
但是，它也降低了可見性，因此僅是REST中的可選約束。

繼續新增統一介面的約束 形成了REST樣式 提高了（可見性）,統一的介面會降低效率，因為資訊是以標準化形式而不是特定於應用程式需求的形式進行傳輸的。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-GJCfxeF2-1601014499877)(/Users/cuijie/Library/Application Support/typora-user-images/image-20200922105724359.png)]

REST (簡單性、網路效率、可伸縮性、可見性、可靠性、可移植性、可以執行、可擴充套件性、可配置型、使用者可察覺的效能、可重用性)

整體上應用時會強調元件互動的可伸縮性，介面的通用性，元件的獨立部署以及中間元件，以減少互動延遲，增強安全性並封裝舊系統

REST提供了一組體系結構約束，這些約束在整體上應用時會強調元件互動的可伸縮性，介面的通用性，元件的獨立部署以及中間元件，以減少互動延遲，增強安全性並封裝舊系統。

RESTful主要元素

代表性狀態轉移（REST）樣式是分散式超媒體系統中體系結構元素的抽象。REST忽略了元件實現和協議語法的細節.

涵蓋了對元件，聯結器和資料的基本約束，這些約束定義了Web體系結構的基礎.

1. 資料元素

   將資訊從儲存位置移動到人類閱讀器將使用的位置.一般有三個基本選項：

   ​ 1）在資料所在的位置渲染資料並將固定格式的影像傳送給接收者；(客戶端-伺服器樣式)

   ​ 封裝良好，限制嚴格，可伸縮性差

   ​ 2）用渲染引擎封裝資料，然後將兩者傳送給接收者；(移動物件樣式)

   ​ 統一引擎處理，限制範圍，效能較差。

   ​ 3）將原始資料與描述資料型別的後設資料一起傳送給接收者，以便接收者可以選擇自己的呈現引擎。

   ​ 簡單，可伸縮，效能良好，資訊無法隱藏，要求傳送方和接收方達成共識。

   REST為以上三個選項的混合，通過對後設資料的資料型別的共享理解，將所顯示的內容的範圍限制為標準化介面.通過一組標準資料型別及其匹配的傳輸格式進行通訊，這些資料型別是根據接受者的能力或需求以及資源的性質動態選擇的。rest可以將客戶端-伺服器樣式的關注點分離，從而避免伺服器可伸縮性的問題，允許通過通用介面隱藏資訊已實現服務的封裝和演進。

   資料元素	現代網路示例
   資源	超文字引用的預期概念目標
   資源識別符號	URL，URN
   表示	HTML檔案，JPEG影像
   表示後設資料	媒體型別，最後修改時間
   資源後設資料	源連結，替代，變化
   控制資料	if-modified-since，快取控制

2. 資源

   1. REST中資訊的關鍵抽象是一種資源,資源是到一組實體的概念對映,可以命名的任何資訊都可以是資源.
   2. 與物件導向設計類似，資源是以名詞為核心來組織的，首先關注的是名詞。
   3. 一個資源可以由一個或多個URI來標識。URI既是資源的名稱，也是資源在Web上的地址。

3. 表示

   1. 表示是一段對於資源在某個特定時刻的狀態的描述。
   2. "資源"是一種資訊實體，它可以有多種外在表現形式.
   3. 在HTTP請求的頭資訊中一般用Accept和Content-Type欄位指定。

4. 狀態轉換

   1. 在客戶端和伺服器端之間轉移（transfer）代表資源狀態的表述。
   2. 是客戶端和伺服器的一個互動過程，這種轉換是建立在表現層之上的。
   3. 通過統一介面來實現狀態轉換。

RESTful的四個級別

由馬丁·福樂（Martin Fowler）在一片文章中提出:https://martinfowler.com/articles/richardsonMaturityModel.html

第0級 (Remote Procedure Invocation)

• 使用HTTP作為遠端互動的傳輸系統，但不使用任何Web機制.

• 全部使用POST請求，引數放在HTTP協議的body裡面。

• 使用時像是傳統的RPC，比如：基於SOAP的WS。

• 問題是客戶端需要明確知道所有的服務、子服務、入參、出參的各種含義。

第1級 (Resource)

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片儲存下來直接上傳(img-3ObRQdRf-1601014499879)(https://martinfowler.com/articles/images/richardsonMaturityModel/level1.png)]

• 每個URI即代表一個資源
• 不需要面向整個服務對話，而是面向單個資源對話
• 依照資源的方式訪問到服務且可定址。
• 一般用名詞表示資源，且以複數形式出現在URI中。
• 以 “/” 結尾表示一組資源；以"/{**ID}"標識單獨資源

第2級 (Http verb)

• HTTP定義了多種method，被用於表述該請求是哪一類動作。在URI中將不能出現動詞，只能有名詞。

  • GET：主要的獲取資訊方法，大量的效能優化都針對該方法，冪等方法
  • HEAD：類似 GET 方法，但伺服器不傳送 BODY，用以獲取 HEAD 後設資料，冪等方法
  • POST：常用於提交 HTML FORM 表單、新增資源等
  • PUT：更新資源，帶條件時是冪等方法
  • DELETE：刪除資源，冪等方法
  • CONNECT：建立 tunnel 隧道
  • OPTIONS：顯示伺服器對訪問資源支援的方法，冪等方法
  • TRACE：回顯伺服器收到的請求，用於定位問題。有安全風險
  • PATCH：是對 PUT 方法的補充，用來對已知資源進行區域性更新
  • 其他的WebDAV不再贅述，感興趣的課自行搜尋

• HTTP 定義了多種status，使用者表述相應的狀態。針對不同的動作也有不同的狀態含義。
  1** 伺服器收到請求，需要請求者繼續執行操作,HTTP1.0 不支援.

  2** 成功處理請求

  3** 重定向使用 Location 指向的資源或者快取中的資源。(次數不應超過 5 次，以防止死迴圈)

  4** 客戶端出現錯誤

  5** 伺服器端出現錯誤

  詳見 ： https://www.runoob.com/http/http-status-codes.html

  特別說明：

  我們很多請求都使用了200來返回成功執行的請求，但其實2**中有很多帶有具體語義的狀態碼.如：

  建立時不返回200，而返回 201 Created。 表示新資源被建立成功。用於在post請求時被返回。

  刪除時不返回200，而返回 204 No Content。表示沒有進一步需要刪除的資源了。200在delete請求時表示該資源被成功刪除了，但您有需要刪除的相關資源。其語義是不攜帶響應包體，一般用於暗示客戶端無需更新當前頁面的檢視。

  在接收非同步請求時使用202 Accepted。表示已經接受請求，但未處理完成。客戶端會在間隔一段時間（若服務端指定，可以隨狀態一同返回）後迴圈呼叫。

  4** 也很值得說明一下。伺服器接收請求後處理不了，並認為是由於客戶端的錯誤導致的無法處理就會使用4**。

  請求引數驗證失敗時會返回400 Bad Request ，認證失敗時 會返回401 Unauthorized.409 Conflict 一般在put請求時會用到，表示自願已存在。

第3級 (Hypermedia Controls)

• 中文翻譯“超文字驅動”或“將超媒體作為應用狀態的引擎”（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫為HATEOAS）
• 資源之間通過超連結相互關聯，超連結既代表資源之間的關係，也代表可執行的狀態遷移.
• 通過超媒體暴露出伺服器所提供的資源，伺服器提供了哪些資源是在執行時通過解析超媒體發現的，而不是事先定義的。

關於不同層級的總結：

• 級別1通過使用分而治之解決了處理複雜性的問題，將大型服務端點分解為多個資源。
• 級別2引入了一組標準動詞，以便我們以相同的方式處理類似的情況，從而消除了不必要的變體。
• 級別3引入了可發現性，從而提供了使協議更具自記錄性的方法。

參考文章：

https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

https://martinfowler.com/articles/richardsonMaturityModel.html

http://www.ruanyifeng.com/blog/2011/09/restful.html

https://www.cnblogs.com/klb561/p/9286283.html