使用REST風格架構您須要知道的一些事

• 1. REST的由來
• 2. REST的構成
  • 2.1. 資源
  • 2.2. 資源的表述
    • 2.2.1. MIME(Multipurpose Internet Mail Extensions)
    • 2.2.2. 緩存約定
  • 2.3. 資源的自描述
    • 2.3.1. 資源的當前狀態
    • 2.3.2. 操做資源的統一接口
    • 2.3.3. 請求的無狀態
  • 2.4. HATEOAS
• 3. REST與分佈式事物
• 4. REST的典型應用案例
• 5. REST vs RPC
• 6. 總結

1. REST的由來

REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。

上世紀90年代面對高速發展的互聯網規模，HTTP1.0須要進一步改進。Roy Fielding 着手製定HTTP1.1的標準及後續擴展工做。HTTP1.1重視下降WEB系統開發的複雜性(經過加強HTTP的請求頭和響應頭），提升系統的可擴展性（經過更容易的緩存指令）以及其餘性能優化工做（好比長鏈接和多個請求和響應能夠重疊等）。

Roy Fielding在制定HTTP時有一個願景：Web世界的應用程序應隨着不斷的超鏈接跳轉來實現應用系統狀態遷移，因此HTTP應該是一個應用協議，而不是一個純粹的超文本傳輸協議。

這就是REST的由來。當咱們在談論REST的時候，表示咱們在談論Web世界的應用一種基於HTTP的架構風格。

2. REST的構成

2.1. 資源

在restful中資源是核心抽象，任何會被互聯網組件訪問的信息都是資源，並用一個URL/URN來標識。
舉例來講，獲取某網站的2017年10月1號的天氣信息，該網站能夠命名改信息爲http://www.somesite.com/weather/2017/10/1或者 http://www.somesite.com/weather?year=2017&month=10&day=1。客戶端瀏覽器能用GET方法合法的獲取該資源。

若是天氣採集人員要建立2017年10月1號的天氣信息，則用POST方法提交表單給http://www.somesite.com/weather完成建立資源工做。
http://www.somesite.com/weather並無制定哪一天的天氣信息，但它確實資源，這體現資源的抽象性。

2.2. 資源的表述

資源的表述是指資源的表現形式，這些形式由請求方和資源提供方經過HTTP協商指定。包括如下內容：

2.2.1. MIME(Multipurpose Internet Mail Extensions)

MIME是多用途互聯網郵件擴展類型，它是一個互聯網標準，擴展了電子郵件標準，使其可以支持：
非ASCII字符文本；非文本格式附件（二進制、聲音、圖像等）；由多部分（multiple parts）組成的消息體；包含非ASCII字符的頭信息（Header information）。

好比下圖，客戶端表示能接受json（首選），text（次選）以及任意格式（再次選）；服務器端返回json內容給客戶端：

2.2.2. 緩存約定

因此的資源操做包括讀取和更新操做，對於不頻繁更新的數據數據多數能夠進行緩存。這種換成越靠近客戶端，用戶體驗越好，即提升了總體系統的可用性。
HTTP採起多層緩存機制，系統能夠定義本身的緩存策略。（此處是否須要講公共緩存，私有緩存，運行機制？）

其中代理服務器和緩存服務器應該只對公共緩存表述進行緩存，瀏覽器緩存對公共和私有的緩存表述都能進行緩存。一般代理服務器的緩存行爲是用戶所屬組織支持的，不屬於應用系統的行爲。

2.3. 資源的自描述

資源的自描述是指：資源的表述裏面應該包括資源當前狀態的描述，以及對該資源或相關資源進一步操做的超連接。

2.3.1. 資源的當前狀態

資源的當前狀態由如下幾項共同組成：

1. 屬於該資源的信息項目的值，好比訂單的編號，建立日期。
2. 相關資源的連接，好比訂單的客戶連接以及訂單明細連接。
3. 表示資源未來會遷移到某種可能狀態的連接，好比遷移到完成狀態的連接:/order/1/completeness POST
4. 對應該資源與其餘資源相關聯的任何業務規則的求值結果，好比訂單統計表：/order/statistics/year/2017 GET

下圖是一個訂單狀態的json表述：

2.3.2. 操做資源的統一接口

HTTP的初衷是應用層協議，HTTP是REST風格的。HTTP的動做提供了操做字體的統一接口。

動做	接口做用	重複操做效果
POST	建立資源	不冪等
PUT	總體更新資源	冪等
PATCH	部分更新資源	不冪等
DELETE	刪除資源	冪等
GET	獲取資源	冪等

冪等 表示動做的重複執行不會再產生反作用（引發資源狀態變化），好比刪除一個資源後再次刪除也不會產生做用，同時系統也不該該返回錯誤信息，而是老是返回成功。

RPC或者SOAP風格的架構下HTTP是做爲傳輸協議使用。

2.3.3. 請求的無狀態

REST的無狀態是指客戶端請求服務器時，應提供足夠的信息以讓服務器能理解並提供服務。無狀態的好處包括：

1. 改善可見性（監視系統沒必要爲了肯定一個請求的所有性質而去查看請求以外的其餘請求）
2. 改善可靠性（減輕了從局部故障中恢復的任務量）
3. 改善可伸縮性（服務端沒必要在多個請求直接保存狀態，從而容許服務器迅速釋放資源）

缺點：

1. 因爲服務器不能保持會話狀態數據，則會形成在每一次請求中發送大量重複的數據，可能會下降網絡性能。

下圖是請求有狀態和無狀態的對比例子：

2.4. HATEOAS

HATEOAS(The Hypermedia As The Engine Of Application Statue)，中文意思是「將超媒體做爲應用狀態的引擎」，這是REST的最高目標(也叫主要架構約束）。

HATEOAS包括兩個概念：

1. 應用狀態由應用（系統）中的各資源狀態組成，資源狀態的變化致使應用狀態的變化。
2. 經過在資源表述中添加狀態遷移的超連接引導客戶端改變資源狀態。

好比：銷售訂單在建立後，客戶端經過GET操做獲取一個訂單信息，而後請求「審批訂單」連接使訂單變成「已審批「狀態。客戶端再請求」執行訂單「完成訂單。這就是一個簡單工做流程。

3. REST與分佈式事物

分佈式系統中事物是一個重要話題，遺憾的是REST做爲一種系統風格，並無約定對事物管理進行規定。事物是服務器端的事情，不論採用何種事物處理方式都要避免對客戶使用rest服務的影響。

4. REST的典型應用案例

1. GitHub Developer API

好比API：列出pull的評論

GET /repos/:owner/:repo/pulls/:number/reviews

官網： https://developer.github.com/v3/pulls/reviews/

2. LinkIn 開發者中心

好比API：獲取當前用戶的信息

GET /v1/people/~?

官網:https://developer.linkedin.com/zh-cn/docs/rest-api

5. REST vs RPC

REST式的Web服務和RPC式的Web服務在接口定義上的區別是，REST使用HTTP通用方法做爲統一接口的標準詞彙，REST式的Web服務所提供的方法信息都在HTTP方法裏，而RPC式的web服務所提供的方法信息在SOAP/HTTP信封裏（其封裝的格式一般是HTTP或者是SOAP），每一個RPC式的web服務都會公佈一套符合本身商業邏輯的方法詞彙。

RPC的典型案例

1. 百度lbs服務API

好比API: 行政區劃區域檢索，之因此是rpc，是因爲：

1. 在參數中指定了資源格式MIME（此例是json），就是說資源表述由百度官方自定義協議解釋。
2. 返回狀態和錯誤信息封裝在返回結果中，說明對於錯誤處理也由百度官方自定義協議解釋。
3. 返回結果關心的是知足當前接口數據，若是想進一步瞭解街道信息，客戶端須根據獲取街道信息API定義獲取。

http://api.map.baidu.com/place/v2/search?query=ATM機&tag=銀行&region=北京&output=json&ak=您的ak GET

若是通過rest風格改造，行政區劃區域檢索API的返回結果能夠是以下形式：

注：百度lbs不是面向應用狀態遷移設計，所以採用rpc也是合適的。

2.Saleforce SOAP API

Saleforce提供了SOAP（簡單對象訪問協議） API,SOAP 經過發佈WSDL（網絡服務描述語言）文件來描述服務器提供的API的輸入參數結構和返回數據結構以及可能的異常信息。客戶端經過WSDL生成客戶端調用代碼（SOAP語言無關，可跨開發語言調用），就能調用遠程的服務API。

下圖表示表示了Saleforce的提供的API的WSDL：

注：Saleforce也提供了REST的API。

如下是兩者的主要區別：

	REST	RPC
HTTP協議地位	應用協議	傳輸協議或者不用
傳輸協議	HTTP	HTTP或者TCP
消息序列化類型	MIME	MIME或者自定義協議
傳輸性能	中	高
服務處理性能	中	高
接口特色	通用（HTTP動做）	自定義接口動做
應用協議	HTTP	自定義
應用狀態遷移方式	資源狀態變化	業務數據狀態變化
緩存擴展性	強	自定義
客戶端耦協力度（協議）	弱	強
客戶端代碼執行	按需提供（JS,CSS,HTML等）	默認不支持
客戶端的庫支持	不須要	最好有，且和服務同步升級
防火牆穿透力	強	默認不支持
公網組件支持度	現成支持，包括（反向）代理服務器，防火牆，緩存服務器，用戶代理（瀏覽器等）	需自行支持（http傳輸除外）
企業應用標準化程度	低（企業自定義）	中（基於SOAP協議，各廠商產品容易集成）

如下是主流RPC和REST框架

框架	特色	開發語言
Thrift	Thrift是一個跨語言的RPC框架，自帶的代碼生成引擎大幅提升了開發效率，從而使它如此流行。 最初由Facebook團隊設計開發，如今已貢獻給Apache	多語言
Dubbo	Dubbo是阿里巴巴開源的專門爲Java設計的、成熟的RPC框架。支持基本的服務治理，全部服務治理 功能均在Client端集成：服務發現、負載均衡、容錯、監控等	Java
Spring HATEOAS	Spring HATEOAS 能夠很方便建立 基於HATEOAS 原則的REST 風格接口 ， 但須要依賴於 Spring 和 Spring MVC	Java

6. 總結

HTTP的本意是方便應用系統實現REST的架構，不過人們在早期並無意識到它的優勢，所以目前更多使用的是RPC框架，由於REST 對開發人員的能力要求更高。綜上，REST具備如下主要特色：

1. 以HTTP爲應用協議。
2. 基於WEB中間件進行擴展：緩存代理提升緩存擴展，反向代理提供負載均衡和內外網協議轉化（HTTPS和HTTP之間)。
3. 請求的無狀態：因爲服務器沒有會話上下文信息，提升系統的可伸縮性。缺點是傳輸冗餘一些。
4. 多級緩存：客戶端代理，代理服務器，緩存服務器提供了強大緩存能力，提升了系統的可用性。
5. 對資源內容的描述方式，好比MIME協商或者在此基礎上的擴展格式，保證了系統的簡單性和通用性。
6. 資源狀態變化促成應用狀態遷移（HATEOAS），可以使開發者以資源爲中心建模，這種設計相對簡單。
7. 資源表述中連接廣告了應用的狀態流，但並不強迫客戶端進行處理，有利於客戶端平滑升級。