1、引子在移動互聯網、云計算迅猛發展的今天，作為一名Web開發者，如果您還沒聽說過“ REST這個buzzword，顯然已經落伍了。夸張點說，甚至“出了門都不 好意思跟別人打招呼”。盡管如此，對于 REST這個泊來品的理解，大多數人（包括一些資深的架構師）仍然停留在“盲人摸象”的階段。常常聽到各種 各 樣關于REST勺說法，例如：有人說：“我們這套新的API決定不用Web Service （SOAP+WSDL而是直接使用HTTP+JSQN也就是用RESTful的方式 來開發。” 不用SOAP甚至也不用XML就自動變成了 RESTful 了。還有人認 為：REST與傳統的Web Service其實沒

2、有本質區別，只是對于 URI的構造方式 提出了更多要求，而這些要求 WebService完全都可以實現。潛 臺詞是：既生 瑜，何生亮。WebService已經足夠好了，干嘛還要再折騰什么 REST這些對 于REST勺不同說法，果真如此嗎？ REST究竟是什么？是一種新的技 術、一種 新的架構、還是一種新的規范？ 對于這些問題筆者先不解答，為了深入理解 REST是什么，我們需要回顧一下 Web發展的最初年代，從源頭上講講 REST是怎么得來的。Web技術發展與REST的由來Web（萬維網World Wide Web的簡稱）是個包羅萬象的萬花筒，不同的人從不 同 的角度觀察，對于 Web究竟是什么

3、會得出大不相同的觀點。作為 Web開發者， 我們需要從技術上來理解 Web從技術架構層面上看， Web的技術架構包括了四 個基石：URIHTTPHyperText （除了 HTM外，也可以是帶有超鏈接的 XML或 JSONMIME這四個基石相互支撐，促使 Web這座宏偉的大廈以幾何級數的速度發展了起 來。 在這四個基石之上，Web開發技術的發展可以粗略劃分成 以下幾個階段：1. 靜態內容階段：在這個最初的階段，使用Web的主要是一些研究機構。Web由大量的靜態HTM文檔組成，其中大多是一些學術論文。Wet服務器可以被看作是支持超文本的共享文件服務器。2. CGI程序階段：在這個階段， Web服

4、務器增加了一些編程API。通過這些API編寫的應用程序，可以向客戶端提供一些動態變化的內容。Web服務器與應用程序之間的通信，通過 CGI （Common Gatewaynterface ）協 議完成，應用程序被稱作CGI程序。3. 腳本語言階段：在這個階段，服務器端出現了ASP、 PHP、JSP、ColdFusion 等支持 session 的腳本語言技術，瀏覽 器 端出現了 Java Applet 、 JavaScript 等技術。使用這些技術，可以提供 更加豐富的動態內容。4. 瘦客戶端應用階段：在這個階段，在服務器端出現了獨立于Web服務器的應用服務器。同時出現了 WebMV（開發模式

5、，各種 WebMVC開發框架 逐漸流行，并且占據了統治地位。基于這些框架開發的Web應用，通常都是瘦客戶端應用，因為它們是在服務器端生成全部的動態內容。5. RIA 應用階段： 在這個階段，出現了多種 RIA（Rich InternetApplicatio n ）技術，大幅改善了 Web應用的用戶體驗。應用最為廣泛的 RIA技術是DHTML+Ajax Ajax技術支持在不刷新頁面的情況下動態更新 頁面中的局部內容。同時誕生了大量的 Web前端DHTM開發庫，例如 Prototype 、Dojo、ExtJS、jQuery/jQuery UI 等等，很多開發庫都支持 單頁面應用（Single Pa

6、ge Application）的開發。其他的 RIA技術還有Adobe公司的Flex、微軟公司的Silverlight 、Sun公司的JavaFX （現 在為 Oracle 公司所有）等等。6. 移動Web應用階段：在這個階段，出現了大量面向移動設備的Web應用開發技術。除了 Android 、 iOS、 WindowsPhone 等操作系統平臺原生的 開發技術之外，基于HTML5I勺開發技術也變得非常流行。從上述Web開發技術的發展過程看，Web從最初其設計者所構思的主要支持靜 態文檔的階段，逐漸變得越來越動態化。Web應用的交互模式，變得越來越復雜：從靜態文檔發展到以內容為主的門戶網站、電

7、子商務網站、搜索引擎、社交網站，再到以娛樂為主的大型多人在線游戲、手機游戲。在互聯網行業，實踐總是走在理論的前面。Web發展到了 1995年，在CGI、ASP等技術出現之后，沿用了多年、主要面向靜態文檔的 HTTP/1.0 協議已經無法滿 足Web應用的開發需求，因此需要設計新版本的 HTTP協議。在HTTP/1.0協議 專家組之中，有一位年輕人脫穎而出，顯示出了不凡的洞察力，后來他成為了HTTP/1.1協議專家組的負責人。這位年輕人就是 Apache HTTP!艮務器的核心開 發者Roy Fielding ，他還是Apache軟件基金會的合作創始人。Roy Fielding 與他的同事們在H

8、TTP/1.1協議的設計工作中，對于 Web之所以 取得巨大成功，在技術架構方面的因素做了一番深入的總結。 Fielding 將這些 總結納入到了一套理論框架之中，然后使用這套理論框架中的指導原則，來 指 導 HTTP/1.1 協議的設計方向。 HTTP/1.1 協議的第一個草稿是在 1996年1 月發 布的，經過了三年多時間的修訂，于1999年6月成為了 IETF的正式規范（包括了 RFC 2616以及用于對客戶端做身 份認證的 RFC 2617）。 HTTP/1.1 協議設 計的極為成功，以至于發布之后整整 10年時間里，都沒有多少人認為有修訂的 必要。用來指導 HTTP/1.1 協議設計

9、的這套理論 框架，最初是以備忘錄的形式在 專家組成員之間交流，除了 IETF/W3C的專家圈子，并沒有在外界廣泛流傳。 Fielding 在完成 HTTP/1.1 協議的設計工作之后，回到了加州大學歐 文分校繼 續攻讀自己的博士學位。第二年（ 2000年）在他的博士學位論文Architectural Styles and the Design of Network-based Software Architectures 中， Fielding 更為系統、嚴謹地闡述了這套理論框架，并且 使 用這套理論框架推導出了一種新的架構風格，并且為這種架構風格取了一個 令 人輕松愉快的名字“ REST”

10、Representational State Transfer （表述性狀 態轉移）的縮寫。在筆者看來，Fielding這篇博士論文在 Web發展史上的價值，不亞于 Web之父 Tim Berners-Lee 關于超文本的那篇經典論文。然而遺憾 的是，這篇博士論文 在誕生之后的將近 5 年時間里，一直沒有得到足夠的重視。例如 WebService 相關規范SOAP/WSD的設計者們，顯然不大理解 REST是什么，HTTP/1.1究竟 是一個什么樣的協議、為何要設計成這個樣子。這種情況在 2005年之后有了很大的改 善，隨著 Ajax、Ruby on Rails 等新的Web開發技術的興起，在W

11、eb開發技術社區掀起了一場重歸Web架構設計本源 的運動，REST架構風格得到了越來越多的關注。在 2007年1月，支持REST開 發的Ruby on Rails 1.2 版正式發布，并且將支持REST開發作為Rails未來發 展中的優先內容。Ruby on Rails的創始人DHH做了一個名為“ World of Resources”的精彩演講，DHH在 Web開發技術社區中的強大影響力，使得 REST 一下子處在 Web開發技術舞臺的聚光燈之下。今天，各種流行的 Web開發框架，幾乎沒有不支持REST開發的了。大多數 Web 開發者都是通過閱讀某種 REST開發框架的文檔，以及通過一些例子

12、代碼來學習 REST開發的。然而，通過例子代碼來學習REST有非常大的局限性。因為 REST 并不是一種具體的技術，也不是一種具體的規范，REST其實是一種內涵非常豐富的架構風格。通過例子代碼來學習 REST除了學習到一種有趣的Web開發技 術之外，并不能全面深入的理解 REST究竟是什么。甚至還會誤以為這些簡單的 例子代碼就是REST本身，REST不過是一種簡單的Web開發技術而已。就像盲人 摸象一樣，有的人摸到了象鼻子、有的人摸到了象耳朵、有的人摸到了象 腿、 有的人摸到了象尾巴。他們都堅信自己感覺到的大象，才是最真實的大象， 而 其他人的感覺都是錯誤的。對于不理解REST的 Web開發者

13、，人們習慣于展示一些例子代碼來讓他們理解 REST筆者不贊同上述做法。如果 Web開發者想要深入理解REST是什么，就很 難避開Fielding的這篇博士論文。筆者在本文中對于REST是什么的介紹，也 是基于 Fielding 的博士論文的。盡管 如此，筆者強烈建議本文的讀者親自去通 讀一下 Fielding 的博士論文，就像想 要了解孔子的思想應該直接去讀論語 等著作，而不是首先去讀其他人的轉述一樣。筆者在本文中也僅僅是努力不 做 一個把經書念錯了的歪嘴與尚而已。那么，下面我們言歸正傳。在 Fielding 的這篇名為 Architectural Styles and the Design

14、of Networkbased Software Architectures 的博士論文（中文版名為架構風格與基于網 絡的軟件架構設計）中，提出了一整套基于網絡的軟件（即所謂的“分布 式 應用”）的設計方法，值得所有分布式應用的開發者仔細閱讀、深入體會。在論文的前三章中， Fielding 在批判性繼承前人研究成果的基礎上，建立起來 一整套研究與評價軟件架構的方法論。這套方法論的核心是“架構風格”這 個 概念。架構風格是一種研究與評價軟件架構設計的方法，它是比架構更加抽 象的概念。一種架構風格是由一組相互協作的架構約束來定義的。架構約束是指軟件的運行環境施加在架構設計之上的約束。在論文的第四章

15、中，Fielding研究了 Web這樣一個分布式系統對于軟件架構設 計提出了哪些需求。在第五章中，Fielding將第四章 Web提出的需求具體化為一些架構約束，通過逐步添加各種架構約束，推導出來了REST這種新的架構風格。REST架構風格的推導過程如下圖所示：圖1： REST所繼承的架構風格約束(原圖可在這里下載)vf sbJcmotile心占旳Shared曲VW地在圖1中，每一個橢圓形里面的縮寫詞代表了一種架構風格，而每一個箭頭邊的單詞代表了一種架構約束。REST架構風格最重要的架構約束有6個:客戶-服務器(Client-Server )通信只能由客戶端單方面發起，表現為請求-響應的形式。

16、無狀態(Stateless )通信的會話狀態(Session State)應該全部由客戶端負責維護緩存(Cache)響應內容可以在通信鏈的某處被緩存，以改善網絡效率統一接口( Un iform In terface )通信鏈的組件之間通過統一的接口相互通信，以提高交互的可見性。通過限制組件的行為（即，每個組件只能“看到”與其交互的緊鄰層），將 架 構分解為若干等級的層。按需代碼（Code-On-Demand可選）支持通過下載并執行一些代碼（例如 Java Applet、Flash或JavaScript ）， 對客戶端的功能進行擴展。在論文中推導出的REST架構風格如下圖所示：圖2： REST架

17、構風格（原圖可在這里下載）icnl Corrwdor: O) Clperit *Cacho Server ConnecterServer+Cacbet而HTTP/1.1協議作為一種REST架構風格的架構實例，其架構如下圖所示: 圖3: 個基于REST勺架構的過程視圖（原圖可在這里下載）tliert Connector: CD Q ient+Cachei CED Server Connector CD Swvar+Cache!用戶代理處在三個并行交互（a、b與c）的中間。用戶代理的客戶端連接器 緩 存無法滿足請求，因此它根據每個資源標識符的屬性與客戶端連接器的配置，將每個請求路由到資源的來源。請

18、求（a）被發送到一個本地代理，代理隨后訪 問一個通過DNSS找發現的緩存網關，該網關將這個請求轉發到一個能夠滿足該請求的來源服務器，服務器的內部資源由一個封裝過的對象請求代理（object request broker）架構來定義。請求（b）直接發送到一個來源服務 器，它能夠通過自己的緩存來滿足這個請求。請求（c）被發送到一個代理，它能夠直接訪問 WAIS（ 種與Web架構分離的信息服務），并將 WAIS的響應翻 譯為一種通用的連接器接口能夠識別的格式。每一個組件只知道與它們自己的客戶端或服務器連接器的交互；整個過程拓撲是我們的視圖的產物。通過比較圖2與圖3,讀者不難發現這兩張圖中的架構是 高

19、度一致的。對于 HTTP/1.1協議為何要設計成這個樣子，讀者想必已經有所領悟。在論文的第六章中，Fielding對于到2000年為止在Web基礎架構協議的設計 與 開發方面的一些經驗教訓進行了深入的分析。其中，“HTTF不是RPC、“HTTP不是一種傳輸協議”兩部分值得讀者反復閱讀。時至13年之后的今日，對于HTTP協議的誤解仍然廣泛存在。以上簡要介紹了 Fielding博士論文中的內容。為了幫助讀者仔細閱讀 Fielding的博士論文，筆者整理了一套Fielding博士論文的導讀，將在本專 欄后續文章中載出。REST羊解REST究竟是什么？因為REST的內涵非常豐富，所以很難用一兩句話解釋

20、清楚 這個問題。首先，REST是 Web自身的架構風格。RES也是Web之所以取得成功的技術架構 方面因素的總結。REST是世界上最成功的分布式應用架構風格（成功案例：Web還不夠嗎？）。它是為 運行在互聯網環境 的 分布式 超媒體系統量身定 制的。 互聯網環境與企業內網環境有非常大的差別，最主要的差別是兩個方面：可伸縮性需求無法控制：并發訪問量可能會暴漲，也可能會暴跌。安全性需求無法控制：無法控制客戶端發來的請求的格式，很可能會是惡意的請求。而所謂的“超媒體系統”，即，使用了超文本的系統。可以把“超媒體”理解為超文本+媒體內容。REST是 HTTP/1.1協議等 Web規范的設計指導原則，H

21、TTP/1.1協議正是為實現 REST風格的架構而設計的。新的 Web規范，其設計必須符合 REST的要求，否 則整個Web的體系架構會因為引入嚴重矛盾而崩潰。這句話不是危言聳聽，做個類比，假如蘇州市政府同意在市區著名園林的附近大型土木，建造大量具有后現代風格的摩天大樓，那么不久之后世界聞名的蘇州園林美景將不復存在。上述這些關于“ REST是什么”的描述，可以總結為一句話：REST是所有Web應用都應該遵守的架構設計指導原則。當然，REST并不是法律，違反了 REST的指導原則，仍然能夠實現應用的功能。但是違反了REST的指導原則，會付出很多代價，特別是對于大流量的網站而言。要深入理解REST

22、需要理解REST勺五個關鍵詞:1. 資源(Resource)2. 資源的表述(Representation ) 狀3. 態轉移(State Transfer ) 統一4. 接口( Un iform In terface) 超文5. 本驅動(Hypertext Driven )什么是資源？所體應首資源是一種看待服務器的方式，即，將服務器看作是由很多離散的資源組成 每個資源是服務器上一個可命名的抽象概念。因為資源是一個抽象的概念， 以它不僅僅能代表服務器文件系統中的一個文件、數據庫中的一張表等等具 的東西，可以將資源設計的要多抽象有多抽象，只要想象力允許而且客戶端 用開發者能夠理解。與面向對象設計

23、類似，資源是以名詞為核心來組織的， 先關注的是名詞。一個資源可以由一個或多個 URI來標識。URI既是資源的名 稱，也是資源在 Web上的地址。對某個資源感興趣的客戶端應用，可以通過資 源的URI與其進行交互。什么是資源的表述？資源的表述是一段對于資源在某個特定時刻的狀態的描述。可以在客戶端 -服務 器端之間轉移(交換)。資源的表述可以有多種格式，例如 HTML/XML/JSO純 文本/圖片/視頻/音頻等等。資源的表 述格式可以通過協商機制來確定。請求 - 響應方向的表述通常使用不同的格式。什么是狀態轉移？狀態轉移(state transfer )與狀態機中的狀態遷移(state transi

24、tion )的 含義是不同的。狀態轉移說的是：在客戶端與服務器端之間轉移(transfer )代表資源狀態的表述。通過轉移與操作資源的表述，來間接實現操作資源的目的。什么是統一接口？RESTg求，必須通 過統一的接口來對資源執行各種操作。對于每個資源只能執 行一組有限的操作。以 HTTP/1.1協議為例，HTTP/1.1協議定義了一個操作資 源的統一接口，主要包括以下內容：7 個 HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONSHTTP頭信息(可自定義)HTTH向應狀態代碼(可自定義)一套標準的內容協商機制一套標準的緩存機制一套標準的客戶端身份認證機制

25、REST還要求，對于資源執行的操作，其操作語義必須由 HTTP?肖息體之前的部 分完全表達，不能將操作語義封裝在 HTTP?息體內部。這樣做是為了提高交互 的可見性，以便于通信鏈的中間組件實現緩存、安全審計等等功能。什么是超文本驅動？“超文本驅動”又名“將超媒體作為應用狀態的引擎” (Hypermedia As TheEngine Of ApplicationState，來自Fielding 博士論文中的一句話，縮寫 為HATEOAS。將Web應用看作是一個由很多狀態(應用狀態)組成的有限狀態機。資源之間通過超鏈接相互關聯，超鏈接既代表資源之間的關系，也代表可執行的狀態遷移。在超媒體之中不僅僅

26、包含數據，還包含了狀態遷移的語義。以超媒體作為引擎，驅動 Web應用的狀態遷移。通過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時通過解析超媒體發現的，而不是事先 定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協議。客戶 端應該依賴的是超媒體的狀態遷移語義，而不應該對于是否存在某個URI或URI的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態遷移語義能夠長期保 持穩定。一旦讀者理解了上述REST的五個關鍵詞，就很容易理解REST風格的架構所具 有的6個的主要特征：面向資源(Resource Oriented )可尋址(Addressability )連

27、通性(Connectedness)無狀態(Statelessness )統一接口(Un iform In terface )超文本驅動(Hypertext Driven )這6個特征是REST架構設計優秀程度的判斷標準。其中，面向資源是REST最明顯的特征，即，REST架構設計是以資源抽象為核心展開的。可尋址說的是： 每一個資源在 Web之上都有自己的地址。連通性說的是：應該盡量避免設計孤立的資源，除了設計資源本身，還需要設計資源之間的關聯關系，并且通過超鏈接將資源關聯起來。無狀態、統一接口是REST勺兩種架構約束，超文本驅動是REST的個關鍵詞，在前面都已經 解釋過，就不再贅述了。從架構風格

28、的抽象高度來看，常見的分布式應用架構風格有三種:分布式對象(Distributed Objects，簡稱 DO架構實例有 CORBA/RMI/EJB/DCOM/.NETemoting 等等遠程過程調用（Remote Procedure Call ,簡稱RPC架構實例有 SOAP/XML-RPC/Hessian/FlashAMF/DW等等表述性狀態轉移（Representational State Transfer ，簡稱 REST架構實例有HTTP/WebDAVDC與 RPC這兩種架構風格在企業應用中非常普遍，而 REST則是Web應用的架 構風格，它們之間有非常大的差別。REST與 DO的差

29、別在于：REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在 不同的編程語言中，對象的定義有很大差別，所以DO風格的架構通常都是與某種編程語言綁定的。跨語言交互即使能實現，實現起來也會非常 復雜。而REST中的資源，貝皖全中立于開發平臺與編程語言，可以使用 任何編程語言來實現。DO中沒有統一接口的概念。不同的API，接口設計風格可以完全不同。DO也不支持操作語 義對于中間組件的可見性。DO中沒有使用超文 本，響應的內容中只包含對象本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比 DO更高。REST支持數據流與管道，DO不支持數據流與管道。DO風格通常會帶來 客戶

30、端與服務器端的緊耦合。在三種架構風格之中，DO風格的耦合度是 最大的，而REST的風格耦合度是最小的。 REST松耦 合的源泉來自于統一接口 +超文本驅動。REST與 RPC勺差別在于：REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風格的 架構建模是以名詞為核心的，RPC風格的架構建模是以動 詞為核心的。 簡單類比一下，REST是面向對象編程，RPC則是面向過程編程。RPC中沒有統一接口的概念。不同的 API，接口設計風格可以完全不同。RPC也不支持操作語義對于中間組件的可見性。RPC中沒有使用超文本，響應的內容中只包含消息本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比RPC更高。REST支持數據流與管道，RPC不支持數據流與管道。因為使用了平臺中立的消息，RPC風格的耦合度比DO風格要小一些，但是RPC風格也常常會帶來客戶端與服務器端的緊耦合。支持統一接口+超文本