REST即表述性狀態傳遞(英文:Representational State Transfer,簡稱REST)是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。git
上世紀90年代面對高速發展的互聯網規模,HTTP1.0須要進一步改進。Roy Fielding 着手製定HTTP1.1的標準及後續擴展工做。HTTP1.1重視下降WEB系統開發的複雜性(經過加強HTTP的請求頭和響應頭),提升系統的可擴展性(經過更容易的緩存指令)以及其餘性能優化工做(好比長鏈接和多個請求和響應能夠重疊等)。github
Roy Fielding在制定HTTP時有一個願景:Web世界的應用程序應隨着不斷的超鏈接跳轉來實現應用系統狀態遷移,因此HTTP應該是一個應用協議,而不是一個純粹的超文本傳輸協議。web
這就是REST的由來。當咱們在談論REST的時候,表示咱們在談論Web世界的應用一種基於HTTP的架構風格。json
在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方法合法的獲取該資源。api
若是天氣採集人員要建立2017年10月1號的天氣信息,則用POST方法提交表單給http://www.somesite.com/weather
完成建立資源工做。
http://www.somesite.com/weather
並無制定哪一天的天氣信息,但它確實資源,這體現資源的抽象性。瀏覽器
資源的表述是指資源的表現形式,這些形式由請求方和資源提供方經過HTTP協商指定。包括如下內容:緩存
MIME是多用途互聯網郵件擴展類型,它是一個互聯網標準,擴展了電子郵件標準,使其可以支持:
非ASCII字符文本;非文本格式附件(二進制、聲音、圖像等);由多部分(multiple parts)組成的消息體;包含非ASCII字符的頭信息(Header information)。性能優化
好比下圖,客戶端表示能接受json(首選),text(次選)以及任意格式(再次選);服務器端返回json內容給客戶端:服務器
因此的資源操做包括讀取和更新操做,對於不頻繁更新的數據數據多數能夠進行緩存。這種換成越靠近客戶端,用戶體驗越好,即提升了總體系統的可用性。
HTTP採起多層緩存機制,系統能夠定義本身的緩存策略。(此處是否須要講公共緩存,私有緩存,運行機制?)restful
其中代理服務器和緩存服務器應該只對公共緩存表述進行緩存,瀏覽器緩存對公共和私有的緩存表述都能進行緩存。一般代理服務器的緩存行爲是用戶所屬組織支持的,不屬於應用系統的行爲。
資源的自描述是指:資源的表述裏面應該包括資源當前狀態的描述,以及對該資源或相關資源進一步操做的超連接。
資源的當前狀態由如下幾項共同組成:
下圖是一個訂單狀態的json表述:
HTTP的初衷是應用層協議,HTTP是REST風格的。HTTP的動做提供了操做字體的統一接口。
動做 | 接口做用 | 重複操做效果 |
---|---|---|
POST | 建立資源 | 不冪等 |
PUT | 總體更新資源 | 冪等 |
PATCH | 部分更新資源 | 不冪等 |
DELETE | 刪除資源 | 冪等 |
GET | 獲取資源 | 冪等 |
冪等 表示動做的重複執行不會再產生反作用(引發資源狀態變化),好比刪除一個資源後再次刪除也不會產生做用,同時系統也不該該返回錯誤信息,而是老是返回成功。
RPC或者SOAP風格的架構下HTTP是做爲傳輸協議使用。
REST的無狀態是指客戶端請求服務器時,應提供足夠的信息以讓服務器能理解並提供服務。無狀態的好處包括:
缺點:
下圖是請求有狀態和無狀態的對比例子:
HATEOAS(The Hypermedia As The Engine Of Application Statue),中文意思是「將超媒體做爲應用狀態的引擎」,這是REST的最高目標(也叫主要架構約束)。
HATEOAS包括兩個概念:
好比:銷售訂單在建立後,客戶端經過GET操做獲取一個訂單信息,而後請求「審批訂單」連接使訂單變成「已審批「狀態。客戶端再請求」執行訂單「完成訂單。這就是一個簡單工做流程。
分佈式系統中事物是一個重要話題,遺憾的是REST做爲一種系統風格,並無約定對事物管理進行規定。事物是服務器端的事情,不論採用何種事物處理方式都要避免對客戶使用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
REST式的Web服務和RPC式的Web服務在接口定義上的區別是,REST使用HTTP通用方法做爲統一接口的標準詞彙,REST式的Web服務所提供的方法信息都在HTTP方法裏,而RPC式的web服務所提供的方法信息在SOAP/HTTP信封裏(其封裝的格式一般是HTTP或者是SOAP),每一個RPC式的web服務都會公佈一套符合本身商業邏輯的方法詞彙。
RPC的典型案例
1. 百度lbs服務API
好比API: 行政區劃區域檢索,之因此是rpc,是因爲:
http://api.map.baidu.com/place/v2/search?query=ATM機&tag=銀行®ion=北京&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 |
HTTP的本意是方便應用系統實現REST的架構,不過人們在早期並無意識到它的優勢,所以目前更多使用的是RPC框架,由於REST 對開發人員的能力要求更高。綜上,REST具備如下主要特色: