架構模式之REST架構

　　直至今日，分佈式系統(Distributed System)已經取得了大規模的應用，特別是Web的發展，已經給軟件開發帶來了翻天覆地的變化，這一點已經毋庸置疑了。

　　構建分佈式系統經常使用的技術一般就是使用分佈式對象(DO)，遠程過程調用(RPC)方式。Web的架構爲構建分佈式系統帶來了全新的開發方式，它拋棄了大量重量級、專家級的中間件，採用各類簡單的中間件來知足企業級的需求，例如可靠性，安全，事務等。

 

REST架構

　　Web的基礎架構就是REST架構，雖然Web開發從HTTP誕生那天起就應該是REST方式的，可是幾乎全部當時的開發者都是使用傳統的DO或者RPC去開發Web這個特殊的分佈式系統。

　　REST是英文Representational State Transfer的縮寫，中文翻譯爲「表述性狀態轉移」。它是由Roy Thomas Fielding博士在2000年首次提出的。在這篇論文中，博士爲咱們描繪了開發基於互聯網的網絡軟件的藍圖。因爲這篇論文學術性太強，致使它並未引發程序員們的注意。直到ROR(Ruby On Rails) 風行起來，它所宣揚的REST架構才真正的爲人們所熟悉。可是ROR所提倡的只不過是使用HTTP協議完成簡單的CRUD操做，離真正的REST架構還有很長一段路要走。在2008年的某次大會(不記得了)上，Fielding博士終於提出了真正的REST架構的核心思想： REST架構就是使用超媒體做爲應用狀態引擎(HATEOAS，即hypermedia as the engine of application state)。

 

REST核心

　　 REST架構的核心理念就是使用HTTP做爲應用協議操做網絡資源，而且以超媒體(hypermedia)做爲應用狀態轉移的載體。這裏有如下幾個重要的概念：

1. 資源

　　任何能夠在網絡上訪問的數據都是資源，爲了讓其餘的系統能訪問這些資源，能夠採用統一資源標識符(URI)來標識每個資源。在Web開發中，最爲經常使用的一種URI就是URL了。對於資源來講，因爲每一個系統對它的描述格式是不一樣的，這就致使同一個資源可能使用不一樣的表述方式，好比JSON格式，XML格式的。在REST架構中，資源的URL中通常不區分每種格式，格式交由Http Header去處理，好比application/json。

2. HTTP協議

　　REST架構使用HTTP做爲應用協議去訪問Web上的資源，而不是像傳統的Web Service同樣只是把HTTP當作一種傳輸協議。把HTTP當作應用協議體現爲充分利用HTTP協議的消息來描述應用業務，體現爲如下幾點：

第一點，利用HTTP的Verb動詞去描述應用的業務邏輯。好比：

GET 請求獲取Request-URI所標識的資源，用於獲取業務數據。
POST 在Request-URI所標識的資源後附加新的數據，用於建立業務數據。
PUT 請求服務器存儲一個資源，並用Request-URI做爲其標識，用於更新業務數據。
PATCH 若是說PUT是更新整個資源的話，PATCH能夠只更新資源的一部分。
DELETE 請求服務器刪除Request-URI所標識的資源，用於刪除業務數據。
這幾個是經常使用的完成CRUD操做的動詞。其餘的還有像：
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭。
TRACE 請求服務器回送收到的請求信息，主要用於測試或診斷。
CONNECT 保留未來使用。
OPTIONS 請求查詢服務器的性能，或者查詢與資源相關的選項和需求。

　　具體的一個例子是，在業務邏輯中，咱們有一個功能是獲取一個員工的信息，在實現這個分佈式應用的時候，咱們就使用GET方法去訪問指定的URI來申請員工的信息。這就是使用HTTP的動詞去描述應用的業務。

第二點，使用HTTP的狀態響應代碼來描述業務邏輯的執行結果。

　　這一點不用多說，好比200來表示獲取資源成功，201來表示資源建立成功，資源更新成功，404表示沒有找到請求的資源，500表示服務器內部出錯。

第三點，使用HTTP消息頭的其餘一些內容來輔助描述業務的數據和狀態。

　　好比使用消息頭中表示消息體類型的Content-Type，用於表示傳輸的數據新舊的Etag和Last-Modified，用於更新數據配合Etag使用的If-Match，用於緩存的Cache-Control，用於受權的Authorization等。

第四點，使用HTTP消息體中的超媒體表示應用程序的狀態。

　　在老式的Web開發中，你們都使用URL隧道技術(來源於REST in Practice一書的稱呼)，其實就是把業務數據嵌入在了URL中，當作查詢字符串處理，這在REST架構中是不能接受的。 嚴格的REST架構認爲REST架構的先決條件就是使用超媒體做爲應用程序的狀態引擎。按個人理解，就是消息體存放的內容就是超媒體，它們描述了業務的當前狀態和接下來可能的狀態，根據這些描述，客戶端就知道了業務接下來可能的操做。

　　好比在電子商務網站中，若是客戶下了一個訂單的話，客戶會使用POST去建立一個訂單，這個時候消息體包含的就是訂單的一些數據，當服務端收到這個Request後，會在後端數據庫中建立訂單信息，而後會在Response的消息體中返回建立的訂單的信息幷包含接下來客戶能夠作的步驟，這些步驟一般就是一些超連接，好比使用GET獲取訂單的最新狀態，使用DELETE刪除該訂單，或者使用POST建立付費申請資源等等。

3. 超媒體

　　其實超媒體並非什麼神祕的概念，超媒體只是超級媒體的縮寫。超媒體是一種採用非線性網狀結構對塊狀多媒體信息（包括文本、圖像、視頻等）進行組織和管理的技術。 超媒體在本質上和超文本是同樣的，只不過超文本技術在誕生的初期管理的對象是純文本，因此叫作超文本。隨着多媒體技術的興起和發展，超文本技術的管理對象從純文本擴展到多媒體，爲強調管理對象的變化，就產生了超媒體這個詞。

　　鏈接各類媒體的形式就是超連接，因此超連接是超媒體的核心元素。在REST架構中，這個思路一樣成立，消息體中的超媒體，核心的元素也就是超連接，各類形式表示的超連接；這些超連接能夠被客戶端很容易的就能解析，好比一般可使用XHTML做爲超媒體載體，由於XHTML有超連接元素，也可使用Atom做爲超媒體載體，由於Atom也有link元素。

　　使用超媒體後，程序的業務邏輯再也不像是Web Service開發同樣，是由WSDL描述的接口去限定了，而是所有由超媒體(超連接)去驅動。這樣當Service作出一些修改後，只會反映到相應的連接中，不須要客戶端作出任何的硬性修改(好比Web Service開發中接口的修改)。

 

REST成熟度模型

　　REST架構興起之後，你們就須要給這些凌亂的認爲實現了REST思想的網站評定是否知足REST的架構風格。認同比較多的就是Richardson的成熟度模型，Martin Fowler大師也這麼談論，以下圖所示：

第0級(level 0)

　　這個級別的實現一般只有一個URI入口。應用程序也只是把HTTP做爲一種普通的傳輸協議，在這之上構建應用層的協議實現遠程Service的調用，這和CORBA，SOAP，POX(Plain Old XML)調用沒有太多分別。

第1級(level 1)

　　這個級別的實現使用了大量的URI來描述各類不一樣的資源(Resource)，同時把複雜的Service的分解爲多個資源。可是實現應用的時候只使用單個的HTTP動詞(一般是GET或POST)來完成全部的業務邏輯，業務邏輯的行進方向徹底隱藏在URI中(查詢字符串中的參數)，大多數現行的網站都屬於這個級別。

第2級(level 2)

　　在第一級的基礎之上，這個級別引入HTTP標準的動詞詞彙，用於增強客戶端和資源URI的交互的語義性。好比使用POST/GET/PUT/DELETE完成常見的CRUD操做。在使用標準語義操做詞彙的同時，還運用HTTP的標準的CODE代碼來表達交互操做的結果。例如200/201/400等表達不一樣的交互操做結果。一些設計良好的網站屬於這個級別，好比亞馬遜S3服務，基於ROR建立的許多服務。

第3級(level 3)

　　在第二級的基礎之上，這個級別增強了狀態轉換的表達，增強了狀態切換的可發現性。這個級別實現了HATEOAS(Hypertext As The Engine of Application State)的機制，在每個服務器端返回給客戶端的消息體中加上一些能夠幫助客戶端了解和指導可能存在的link，從而按照不一樣的link實現不一樣的狀態的遷移。這就比如給客戶端程序就像一個使用瀏覽器的人同樣，資源的Representation就比如展示在瀏覽器中的HTML同樣。瀏覽的人能夠經過HTML中的link實現不一樣頁面的瀏覽。經過HATEOAS，準確的來講只須要對外廣告資源的入口，就能夠完成全部資源狀態之間的切換和導航。

 

Web Service安魂曲？(源於REST in Practice一書的稱呼)

　　目前來看，答案應該是否認的。我我的以爲緣由有下列幾點：

　　首先，不少開發人員已經熟悉了Web Service的開發方式，即便REST相比而言優點更明顯，可是因爲不少人比較懶，都傾向於採用成熟的技術，心裏通常也抵制新的技術(固然不少人仍是熱衷於新技術的)，因此Web Service開發還會持續較長一段時間。

　　其次，不少Web Service開發人員都是專家級的人物，轉向新技術的話其優點將損失殆盡。

　　最後，Web Service開發的標準WS-*日趨完善，功能日益強大，並且針對不少的內部平臺，WS開發仍然具備強大的吸引力。

　　總的來講，Web Service與REST開發應該不是嚴格的替代關係，它們會長久的並存並向前發展，就如同REST架構也不會替代MVC開發同樣，由於它們都有各自最擅長的場景。