于洋

摘? 要: RESTful架構風格已經提出將近20年,在移動互聯網和微服務大潮下,RESTful架構風格服務已經成為提供web服務的最主流技術,經過多年的應用和沉淀,該架構風格已經成熟穩定,而對當前階段的RESTful架構風格進行系統性梳理和論述的文檔并不多,文章從RESTful架構風格的特點、演變和興衰等角度,對該架構風格進行綜合性闡述。
關鍵詞: REST; RESTful架構風格; 微服務; 架構
中圖分類號:TP399? ? ? ? ? 文獻標識碼:A? ? ?文章編號:1006-8228(2020)04-10-04
Review of RESTful architecture style and its evolution
Yu Yang
(Power China Huadong Engineering Corporation Limited, Hangzhou, Zhejiang 310014, China)
Abstract: RESTful architecture has been put forward for almost 20 years, and under the tendency of mobile Internet and micro service, RESTful services have become the most popular technology in Web service. After years of application, this architecture has been mature and stable, but there are very few papers discuss the current RESTful architecture systematically. This paper will make a comprehensive demonstration of RESTful architecture style, from the aspect of its feature, evolution and its rise and fall.
Key words: REST; REST architecture style; micro service; architecture
0 引言
在移動互聯網的大潮下,移動端的開發需求越來越多,Web端的開發也逐漸流行起前后端分離的架構,這些都要求后臺服務采用RESTful架構風格的API,如果開發者對RESTful架構風格不甚了解,開發出的RESTful API總會貌合神離,既讓開發者無法提供規范的Web服務,也會讓服務消費者困惑。現在RESTful架構風格已經提出將近20年,經過多年應用和沉淀,該架構風格已經成熟穩定,有必要對此架構風格進行系統性梳理,以便讓開發者快速達成共識,提高協作效率。
1 RESTful架構風格概述
RESTful架構風格最初由Roy T. Fielding(HTTP/1.1協議專家組負責人)在其2000年的博士學位論文中提出[1]。HTTP就是該架構風格的一個典型應用。從其誕生之日開始,就因其可擴展性和簡單性受到越來越多的架構師和開發者的青睞。一方面,隨著云計算和移動計算的興起,許多企業愿意在互聯網上共享自己的數據、功能;另一方面,在企業中,RESTful API(也稱RESTful Web服務)逐漸超越SOAP成為實現SOA的重要手段之一。時至今日,RESTful架構風格已成為企業級服務的標配。
REST即Representational State Transfer的縮寫,可譯為“表現層狀態轉化”。REST最大的幾個特點為:資源、統一接口、URI和無狀態。
1.1 RESTful架構風格的特點
1.1.1 資源
所謂“資源”,即網絡上的一個實體,或網絡上的一個具體信息[2]。資源通過某種載體承載內容,文本可以用txt或HTML、XML等標記型文本格式表現,其他資源可以采用二進制格式。
與資源相對應的是數據,數據(尤其是數據庫)是一種更抽象的、對計算機更高效和友好的信息表現形式,是面向計算機抽象的邏輯模型。
資源和數據關系如圖1所示。
1.1.2 統一接口
RESTful架構風格規定,數據的基本操作,即CRUD(create,read,update和delete,即數據的增刪查改)操作,分別對應HTTP方法,統一了數據操作的接口,僅通過HTTP方法,即可完成對數據的所有增刪查改工作[3]。
GET(SELECT):從服務器取出資源(一項或多項)。
POST(CREATE):在服務器新建一個資源。
PUT(UPDATE):在服務器更新資源(客戶端提供完整資源數據)。
PATCH(UPDATE):在服務器更新資源(客戶端提供需要修改的資源數據)。
DELETE(DELETE):從服務器刪除資源。
1.1.3 URI
URI即統一資源定位符,RESTful架構風格要求用URI指向資源,每個URI對應一個特定的資源,一個資源可以有一個或多個URI與之對應。要獲取這個資源,訪問其URI即可,URI就是資源的地址或識別符。在Web開發中,URI通常為URL。
1.1.4 無狀態
所謂無狀態的,即所有的資源,都可以通過URI定位,且這個定位與其他資源無關,不會因為其他資源的變化而改變。與無狀態相對的是有狀態,二者的區別,主要在于操作資源時,是否依賴基于狀態的上下文背景。例如查詢員工工資的應用場景,在有狀態的系統中,查詢工資需要登錄系統,進入查詢工資的頁面,再發起工資查詢請求,以獲取工資的金額,由于查詢工資的每一步操作都依賴于前一步操作,只要前置操作不成功,后續操作就無法執行,因此,這類系統是有狀態的;而在無狀態的系統中,輸入一個url即可得到指定員工的工資信息,沒有前置操作需要依賴,這種場景即為無狀態。
在無狀態的系統中,資源均有URI 與之對應,對資源的操作通過統一的HTTP接口、基于HTTP動詞來響應,這極大降低了RESTful API的學習成本,也使得RESTful架構風格成為一種與開發語言無關、兼容異構系統的架構風格。
1.2 RESTful架構風格的鑒權機制
1.2.1 認證機制
由于RESTful架構風格的系統是無狀態的,用戶認證尤為重要。例如上文提到的員工工資,是一個隱私資源,只有員工本人或其他少數有權限的人有權訪問,禁止用戶隨意查看。RESTful架構風格的系統如果不通過認證機制對資源做限制,所有資源將以公開方式暴露出來,既不合理,也不安全。
認證機制通常是一種獨立的、通用的公共組件,不屬于RESTful架構風格,但卻是RESTful風格系統的基本組成部分,常用的認證機制包括 session auth(即通過用戶名密碼登錄),basic auth,token auth和OAuth[4],在RESTfulAPI開發中常用的認證機制為后三者,隨著RESTfulAPI的廣泛應用,以及OAuth的嚴謹性和安全性,現在OAuth已成為RESTful架構風格中最常用的認證機制,和RESTful架構風格一起,成為企業級服務的標配。
1.2.2 權限機制
在業務系統開發實踐中,通過認證機制確認資源的請求者往往只是RESTful API 鑒權的第一步,接下來還要確認請求者是否被許可使用、修改、刪除或創建資源,這需要使用系統的權限機制。權限機制通常與系統的業務邏輯綁定,因此權限機制在每個系統中各自實現,基于用戶和角色的權限機制具備一定的通用性,如果涉及到對象級的權限機制,每個系統各不相同。
2 RESTful架構風格的演變
2.1 本真REST和hybrid風格
在RESTful架構風格興起之初,存在本真REST和hybrid風格之分。本真REST即上文闡述的RESTful架構風格,具備上述的4個特點,是真正意義上的RESTful風格;而hybrid風格,是最初的一些開發者出于對REST的誤解,或者只是借鑒了RESTful的一些優點,開發的具備一部分RESTful風格的特點服務。
Hybrid風格的特色是,基于HTTP通信協議,使用GET方法獲取資源,用POST方法實現資源的創建、修改和刪除,因此對于獲取資源的API,hybrid風格和本真REST并無二致,但由于它沒有采用REST規定的HTTP動詞進行資源的創建、修改和刪除,因此從本質上講,hybrid風格并非RESTful架構風格。Hybrid風格之所以存在,拋棄誤解的因素,最主要的原因是對傳統RPC風格服務的改造。因此,開發RESTful 服務如果沒有歷史包袱,就不建議使用hybrid風格。
2.2 現在的RESTful架構風格
隨著RESTful架構風格的應用越來越普及,開發者也逐漸發現本真REST潛在的問題。由于本真REST要求用HTTP動詞來實現和開放資源的基本操作(即數據創建、獲取、更新和刪除操作),并以此組合出資源的在實際應用場景中的具體業務邏輯,而CRUD不能有效表達所有的業務和操作。如批量刪除資源操作,如果嚴格使用本真REST API,只有單個資源刪除的API可用,批量刪除時需要循環調用多次該API,這既低效,也對服務器不友好。合理的API應該是只對服務器做一次請求,調用一個API實現批量刪除,在RESTful架構風格下實現該需求,只能采用變通的方法:
⑴ 對于少量數據或有規律數據的批量刪除,可以設計一個API指向資源集,提供對資源集的過濾查詢和刪除服務,批量刪除時請求該服務API,刪除查詢到的所有數據。這里涉及到由對資源刪除操作到提供資源集刪除服務的語義轉換;
⑵ 對于大量無規律數據的批量刪除,要變通刪除語義,把對資源的批量刪除視為資源批量修改的一種特殊情況,將DELETE方法轉換為PUT方法后再進行資源批量操作;而這里不能將DELETE操作變通為POST操作,是由于RESTful架構風格要求操作的冪等性,PUT和DELETE均是冪等的,不冪等的POST操作只允許用于資源創建操作中,因此變通和語義轉換,依然是在RESTful前提下進行的;
⑶ 所以,現在的RESTful架構風格,是在本真REST的基礎上進行了擴展,對CRUD以外的操作,語義化并映射到相對合理的HTTP方法中,再進行API的開發,目前這些變通的API,沒有統一的設計與實現標準。
3 RESTful架構風格的發展
3.1 REST的興起與RPC的衰落
RESTful 架構風格初露頭角之時,面向服務的架構(SOA)[5]已經興起,當時開發SOA系統的技術基礎為RPC技術[6],因此RPC風格API曾是Web Service的主流,其最初是基于XML-RPC協議(一個遠程過程調用(remote procedure call,RPC)的分布式計算協議),后來漸漸被SOAP協議(簡單對象訪問協議(Simple Object Access Protocol))取代;RPC風格的服務,不僅可以用HTTP,還可以用TCP或其他通信協議。
RPC風格的API,受開發服務采用語言的束縛比較大,如.NET框架中,開發web service的傳統方式是使用WCF,基于WCF開發的服務即RPC風格的服務,使用該服務的客戶端通常要用C#來實現,如果使用python或其他語言,很難實現可以直接與服務通信客戶端;進入移動互聯網時代后,RPC風格的API很難在移動終端使用,而RESTful風格的服務,由于可以直接以json等文本格式為數據載體,以HTTP方法統一接口完成數據操作,客戶端的開發不依賴于服務實現的技術,移動終端也可以輕松使用服務,這使得REST逐漸取代RPC成為開發web service的主流架構風格。
3.2 REST的成熟與RPC的再次興起
在移動互聯網的大潮下,RESTful架構風格在Web服務開發上的使用越來越普遍,自2014年微服務架構興起后,RESTful架構風格的應用更是步入新的高峰,現在hybrid風格的服務已鮮有出現,本真REST+鑒權機制已成為企業級服務的共識。隨著應用的普及,一方面RESTful風格日益成熟,演化成了上一章節介紹的模式;另一方面,由于RESTful架構風格只能采用HTTP協議,以文本格式作為數據的載體,其數據傳輸和網絡通信的效率比RPC要差,這在業務量級巨大或性能要求高的系統中,為RPC的再次興起帶來了機會。雖然先前基于SOAP的RPC服務不再是主流,但RPC技術卻一直在發展壯大,現在很多微服務框架,服務間的通信基于支持多種協議的RPC技術,也出現了gRPC等跨語言的RPC技術,這些均在當前微服務大潮下得到廣泛應用。
現在,RESTful架構風格的服務是對外開放服務的主流技術,而在企業內部,甚至在一個系統的各個模塊之間,已經不再是RESTful風格一家獨大的局面,在實際的系統開發中,需要架構師基于現實的要求,選擇合適的服務架構方案。
3.3 GraphQL的興起
RESTful架構風格被廣泛應用后,面對多種多樣的業務場景,開發者開始意識到RESTful風格的API在獲取資源時的便捷性和有效性有待改進。調用RESTfulAPI時,如果想獲取多種類型的資源,開發者需要發起多個不同類型的資源請求,然后在客戶端把資源組合成預期的格式,其有效性和便捷性均不及一個請求獲取預期結果,而這卻正是GraphQL具備的優勢。GraphQL相當于在RESTfulAPI實踐積累的基礎上提出的一種新API風格,潛力巨大,目前還處于萌芽階段。
RESTful架構風格發展至今已經歷了近20個年頭歷練,而GraphQL是2015年左右由FaceBook提出了一種新的API載體,暫時還無法撼動RESTful架構風格在Web服務開發中的地位。
4 結束語
RESTful架構風格已經提出將近20年,在移動互聯網和微服務大潮下,RESTful架構風格服務已經成為提供web服務的最主流技術,經過多年的應用和沉淀,該架構風格已經成熟穩定。雖然隨著技術的發展和業務對技術需求的不斷深入,RESTful架構風格在某些應用場景下也存在力有不逮的情況,但其應用場景和邊界也日益清晰,目前尚未出現衰落的跡象。
目前,RESTful架構風格的服務依然是對外開放服務的主流技術,在企業內部,以及一個系統的各個模塊之間,服務間的調用不再是RESTful風格一家獨大的局面,初露頭角的GraphQL,暫時也無法撼動RESTful架構風格在Web服務開發中的地位。
參考文獻(References):
[1] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures[D].Doctor,CALIFORNIA:UNIVERSITY OF CALIFORNIA,2000.
[2] Leonard Richardson/Sam Ruby.RESTful Web Services[M].California:O'Reilly Media,2007-5-18.
[3] SubbuAllamaraju. RESTful Web Services Cookbook中文版[M].電子工業出版社,2011.
[4] Ryan Boyd.Getting Started with OAuth 2.0[M].O'ReillyMedia,2012-2-29.
[5] 歐陽純萍,李業榮.SOA面向服務體系結構的探討[A].2006通信理論與技術新進展--第十一屆全國青年通信學術會議論文集[C].中國通信學會,2006:766-771
[6] 姜虹.基于Web Services的RPC體系結構的研究[D].西安工業大學碩士學位論文,2008.