Web技術(shù)發(fā)展及REST的由來

1、引子在移動互聯(lián)網(wǎng)、云計算迅猛發(fā)展的今天，作為一名Web開發(fā)者，如果您還沒聽說過“REST”這個buzzword，顯然已經(jīng)落伍了。夸張點(diǎn)說，甚至“出了門都不好意思跟別人打招呼”。盡管如此，對于REST這個泊來品的理解，大多數(shù)人（包括一些資深的架構(gòu)師）仍然停留在“盲人摸象”的階段。常常聽到各種各樣關(guān)于REST的說法，例如：有人說：“我們這套新的API決定不用Web Service（SOAP+WSDL），而是直接使用HTTP+JSON，也就是用RESTful的方式來開發(fā)?！?不用SOAP，甚至也不用XML，就自動變成了RESTful了。還有人認(rèn)為：REST與傳統(tǒng)的Web Service其實(shí)沒有本質(zhì)區(qū)

2、別，只是對于URI的構(gòu)造方式提出了更多要求，而這些要求Web Service完全都可以實(shí)現(xiàn)。潛臺詞是：既生瑜，何生亮。Web Service已經(jīng)足夠好了，干嘛還要再折騰什么REST。這些對于REST的不同說法，果真如此嗎？REST究竟是什么？是一種新的技術(shù)、一種新的架構(gòu)、還是一種新的規(guī)范？對于這些問題筆者先不解答，為了深入理解REST是什么，我們需要回顧一下Web發(fā)展的最初年代，從源頭上講講REST是怎么得來的。Web技術(shù)發(fā)展與REST的由來Web（萬維網(wǎng)World Wide Web的簡稱）是個包羅萬象的萬花筒，不同的人從不同的角度觀察，對于Web究竟是什么會得出大不相同的觀點(diǎn)。作為Web開發(fā)

3、者，我們需要從技術(shù)上來理解Web。從技術(shù)架構(gòu)層面上看，Web的技術(shù)架構(gòu)包括了四個基石：· URI · HTTP · HyperText（除了HTML外，也可以是帶有超鏈接的XML或JSON） · MIME 這四個基石相互支撐，促使Web這座宏偉的大廈以幾何級數(shù)的速度發(fā)展了起來。在這四個基石之上，Web開發(fā)技術(shù)的發(fā)展可以粗略劃分成以下幾個階段：1. 靜態(tài)內(nèi)容階段：在這個最初的階段，使用Web的主要是一些研究機(jī)構(gòu)。Web由大量的靜態(tài)HTML文檔組成，其中大多是一些學(xué)術(shù)論文。Web服務(wù)器可以被看作是支持超文本的共享文件服務(wù)器。 2. CGI程序階段：在這個階段

4、，Web服務(wù)器增加了一些編程API。通過這些API編寫的應(yīng)用程序，可以向客戶端提供一些動態(tài)變化的內(nèi)容。Web服務(wù)器與應(yīng)用程序之間的通信，通過CGI（Common Gateway Interface）協(xié)議完成，應(yīng)用程序被稱作CGI程序。 3. 腳本語言階段：在這個階段，服務(wù)器端出現(xiàn)了ASP、PHP、JSP、ColdFusion等支持session的腳本語言技術(shù)，瀏覽器端出現(xiàn)了Java Applet、JavaScript等技術(shù)。使用這些技術(shù)，可以提供更加豐富的動態(tài)內(nèi)容。 4. 瘦客戶端應(yīng)用階段：在這個階段，在服務(wù)器端出現(xiàn)了獨(dú)立于Web服務(wù)器的應(yīng)用服務(wù)器。同時出現(xiàn)了Web MVC開發(fā)模式，各種Web

5、 MVC開發(fā)框架逐漸流行，并且占據(jù)了統(tǒng)治地位。基于這些框架開發(fā)的Web應(yīng)用，通常都是瘦客戶端應(yīng)用，因?yàn)樗鼈兪窃诜?wù)器端生成全部的動態(tài)內(nèi)容。 5. RIA應(yīng)用階段：在這個階段，出現(xiàn)了多種RIA（Rich Internet Application）技術(shù)，大幅改善了Web應(yīng)用的用戶體驗(yàn)。應(yīng)用最為廣泛的RIA技術(shù)是DHTML+Ajax。Ajax技術(shù)支持在不刷新頁面的情況下動態(tài)更新頁面中的局部內(nèi)容。同時誕生了大量的Web前端DHTML開發(fā)庫，例如Prototype、Dojo、ExtJS、jQuery/jQuery UI等等，很多開發(fā)庫都支持單頁面應(yīng)用（Single Page Application）的開

6、發(fā)。其他的RIA技術(shù)還有Adobe公司的Flex、微軟公司的Silverlight、Sun公司的JavaFX（現(xiàn)在為Oracle公司所有）等等。 6. 移動Web應(yīng)用階段：在這個階段，出現(xiàn)了大量面向移動設(shè)備的Web應(yīng)用開發(fā)技術(shù)。除了Android、iOS、Windows Phone等操作系統(tǒng)平臺原生的開發(fā)技術(shù)之外，基于HTML5的開發(fā)技術(shù)也變得非常流行。 從上述Web開發(fā)技術(shù)的發(fā)展過程看，Web從最初其設(shè)計者所構(gòu)思的主要支持靜態(tài)文檔的階段，逐漸變得越來越動態(tài)化。Web應(yīng)用的交互模式，變得越來越復(fù)雜：從靜態(tài)文檔發(fā)展到以內(nèi)容為主的門戶網(wǎng)站、電子商務(wù)網(wǎng)站、搜索引擎、社交網(wǎng)站，再到以娛樂為主的大型多人

7、在線游戲、手機(jī)游戲。在互聯(lián)網(wǎng)行業(yè)，實(shí)踐總是走在理論的前面。Web發(fā)展到了1995年，在CGI、ASP等技術(shù)出現(xiàn)之后，沿用了多年、主要面向靜態(tài)文檔的HTTP/1.0協(xié)議已經(jīng)無法滿足Web應(yīng)用的開發(fā)需求，因此需要設(shè)計新版本的HTTP協(xié)議。在HTTP/1.0協(xié)議專家組之中，有一位年輕人脫穎而出，顯示出了不凡的洞察力，后來他成為了HTTP/1.1協(xié)議專家組的負(fù)責(zé)人。這位年輕人就是Apache HTTP服務(wù)器的核心開發(fā)者Roy Fielding，他還是Apache軟件基金會的合作創(chuàng)始人。Roy Fielding與他的同事們在HTTP/1.1協(xié)議的設(shè)計工作中，對于Web之所以取得巨大成功，在技術(shù)架構(gòu)方面的

8、因素做了一番深入的總結(jié)。Fielding將這些總結(jié)納入到了一套理論框架之中，然后使用這套理論框架中的指導(dǎo)原則，來指導(dǎo)HTTP/1.1協(xié)議的設(shè)計方向。HTTP/1.1協(xié)議的第一個草稿是在1996年1月發(fā)布的，經(jīng)過了三年多時間的修訂，于1999年6月成為了IETF的正式規(guī)范（包括了RFC 2616以及用于對客戶端做身份認(rèn)證的RFC 2617）。HTTP/1.1協(xié)議設(shè)計的極為成功，以至于發(fā)布之后整整10年時間里，都沒有多少人認(rèn)為有修訂的必要。用來指導(dǎo)HTTP/1.1協(xié)議設(shè)計的這套理論框架，最初是以備忘錄的形式在專家組成員之間交流，除了IETF/W3C的專家圈子，并沒有在外界廣泛流傳。Fielding

9、在完成HTTP/1.1協(xié)議的設(shè)計工作之后，回到了加州大學(xué)歐文分校繼續(xù)攻讀自己的博士學(xué)位。第二年（2000年）在他的博士學(xué)位論文Architectural Styles and the Design of Network-based Software Architectures中，F(xiàn)ielding更為系統(tǒng)、嚴(yán)謹(jǐn)?shù)仃U述了這套理論框架，并且使用這套理論框架推導(dǎo)出了一種新的架構(gòu)風(fēng)格，并且為這種架構(gòu)風(fēng)格取了一個令人輕松愉快的名字“REST”Representational State Transfer（表述性狀態(tài)轉(zhuǎn)移）的縮寫。在筆者看來，F(xiàn)ielding這篇博士論文在Web發(fā)展史上的價值，不亞于Web之

10、父Tim Berners-Lee關(guān)于超文本的那篇經(jīng)典論文。然而遺憾的是，這篇博士論文在誕生之后的將近5年時間里，一直沒有得到足夠的重視。例如Web Service相關(guān)規(guī)范SOAP/WSDL的設(shè)計者們，顯然不大理解REST是什么，HTTP/1.1究竟是一個什么樣的協(xié)議、為何要設(shè)計成這個樣子。這種情況在2005年之后有了很大的改善，隨著Ajax、Ruby on Rails等新的Web開發(fā)技術(shù)的興起，在Web開發(fā)技術(shù)社區(qū)掀起了一場重歸Web架構(gòu)設(shè)計本源的運(yùn)動，REST架構(gòu)風(fēng)格得到了越來越多的關(guān)注。在2007年1月，支持REST開發(fā)的Ruby on Rails 1.2版正式發(fā)布，并且將支持REST開發(fā)

11、作為Rails未來發(fā)展中的優(yōu)先內(nèi)容。Ruby on Rails的創(chuàng)始人DHH做了一個名為“World of Resources”的精彩演講，DHH在Web開發(fā)技術(shù)社區(qū)中的強(qiáng)大影響力，使得REST一下子處在Web開發(fā)技術(shù)舞臺的聚光燈之下。今天，各種流行的Web開發(fā)框架，幾乎沒有不支持REST開發(fā)的了。大多數(shù)Web開發(fā)者都是通過閱讀某種REST開發(fā)框架的文檔，以及通過一些例子代碼來學(xué)習(xí)REST開發(fā)的。然而，通過例子代碼來學(xué)習(xí)REST有非常大的局限性。因?yàn)镽EST并不是一種具體的技術(shù)，也不是一種具體的規(guī)范，REST其實(shí)是一種內(nèi)涵非常豐富的架構(gòu)風(fēng)格。通過例子代碼來學(xué)習(xí)REST，除了學(xué)習(xí)到一種有趣的We

12、b開發(fā)技術(shù)之外，并不能全面深入的理解REST究竟是什么。甚至還會誤以為這些簡單的例子代碼就是REST本身，REST不過是一種簡單的Web開發(fā)技術(shù)而已。就像盲人摸象一樣，有的人摸到了象鼻子、有的人摸到了象耳朵、有的人摸到了象腿、有的人摸到了象尾巴。他們都堅信自己感覺到的大象，才是最真實(shí)的大象，而其他人的感覺都是錯誤的。對于不理解REST的Web開發(fā)者，人們習(xí)慣于展示一些例子代碼來讓他們理解REST，筆者不贊同上述做法。如果Web開發(fā)者想要深入理解REST是什么，就很難避開Fielding的這篇博士論文。筆者在本文中對于REST是什么的介紹，也是基于Fielding的博士論文的。盡管如此，筆者強(qiáng)烈

13、建議本文的讀者親自去通讀一下Fielding的博士論文，就像想要了解孔子的思想應(yīng)該直接去讀論語等著作，而不是首先去讀其他人的轉(zhuǎn)述一樣。筆者在本文中也僅僅是努力不做一個把經(jīng)書念錯了的歪嘴與尚而已。那么，下面我們言歸正傳。在Fielding的這篇名為Architectural Styles and the Design of Network-based Software Architectures的博士論文（中文版名為架構(gòu)風(fēng)格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計）中，提出了一整套基于網(wǎng)絡(luò)的軟件（即所謂的“分布式應(yīng)用”）的設(shè)計方法，值得所有分布式應(yīng)用的開發(fā)者仔細(xì)閱讀、深入體會。在論文的前三章中，F(xiàn)ielding

14、在批判性繼承前人研究成果的基礎(chǔ)上，建立起來一整套研究與評價軟件架構(gòu)的方法論。這套方法論的核心是“架構(gòu)風(fēng)格”這個概念。架構(gòu)風(fēng)格是一種研究與評價軟件架構(gòu)設(shè)計的方法，它是比架構(gòu)更加抽象的概念。一種架構(gòu)風(fēng)格是由一組相互協(xié)作的架構(gòu)約束來定義的。架構(gòu)約束是指軟件的運(yùn)行環(huán)境施加在架構(gòu)設(shè)計之上的約束。在論文的第四章中，F(xiàn)ielding研究了Web這樣一個分布式系統(tǒng)對于軟件架構(gòu)設(shè)計提出了哪些需求。在第五章中，F(xiàn)ielding將第四章Web提出的需求具體化為一些架構(gòu)約束，通過逐步添加各種架構(gòu)約束，推導(dǎo)出來了REST這種新的架構(gòu)風(fēng)格。REST架構(gòu)風(fēng)格的推導(dǎo)過程如下圖所示：圖1：REST所繼承的架構(gòu)風(fēng)格約束（原圖可在

15、這里下載）在圖1中，每一個橢圓形里面的縮寫詞代表了一種架構(gòu)風(fēng)格，而每一個箭頭邊的單詞代表了一種架構(gòu)約束。REST架構(gòu)風(fēng)格最重要的架構(gòu)約束有6個：· 客戶-服務(wù)器（Client-Server） 通信只能由客戶端單方面發(fā)起，表現(xiàn)為請求-響應(yīng)的形式。· 無狀態(tài)（Stateless） 通信的會話狀態(tài)（Session State）應(yīng)該全部由客戶端負(fù)責(zé)維護(hù)。· 緩存（Cache） 響應(yīng)內(nèi)容可以在通信鏈的某處被緩存，以改善網(wǎng)絡(luò)效率。· 統(tǒng)一接口（Uniform Interface） 通信鏈的組件之間通過統(tǒng)一的接口相互通信，以提高交互的可見性。· 分層系統(tǒng)（L

16、ayered System） 通過限制組件的行為（即，每個組件只能“看到”與其交互的緊鄰層），將架構(gòu)分解為若干等級的層。· 按需代碼（Code-On-Demand，可選） 支持通過下載并執(zhí)行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進(jìn)行擴(kuò)展。在論文中推導(dǎo)出的REST架構(gòu)風(fēng)格如下圖所示：圖2：REST架構(gòu)風(fēng)格（原圖可在這里下載） 而HTTP/1.1協(xié)議作為一種REST架構(gòu)風(fēng)格的架構(gòu)實(shí)例，其架構(gòu)如下圖所示：圖3：一個基于REST的架構(gòu)的過程視圖（原圖可在這里下載）用戶代理處在三個并行交互（a、b與c）的中間。用戶代理的客戶端連接器緩

17、存無法滿足請求，因此它根據(jù)每個資源標(biāo)識符的屬性與客戶端連接器的配置，將每個請求路由到資源的來源。請求（a）被發(fā)送到一個本地代理，代理隨后訪問一個通過DNS查找發(fā)現(xiàn)的緩存網(wǎng)關(guān)，該網(wǎng)關(guān)將這個請求轉(zhuǎn)發(fā)到一個能夠滿足該請求的來源服務(wù)器，服務(wù)器的內(nèi)部資源由一個封裝過的對象請求代理（object request broker）架構(gòu)來定義。請求（b）直接發(fā)送到一個來源服務(wù)器，它能夠通過自己的緩存來滿足這個請求。請求（c）被發(fā)送到一個代理，它能夠直接訪問WAIS（一種與Web架構(gòu)分離的信息服務(wù)），并將WAIS的響應(yīng)翻譯為一種通用的連接器接口能夠識別的格式。每一個組件只知道與它們自己的客戶端或服務(wù)器連接器的交互

18、；整個過程拓?fù)涫俏覀兊囊晥D的產(chǎn)物。通過比較圖2與圖3，讀者不難發(fā)現(xiàn)這兩張圖中的架構(gòu)是高度一致的。對于HTTP/1.1協(xié)議為何要設(shè)計成這個樣子，讀者想必已經(jīng)有所領(lǐng)悟。在論文的第六章中，F(xiàn)ielding對于到2000年為止在Web基礎(chǔ)架構(gòu)協(xié)議的設(shè)計與開發(fā)方面的一些經(jīng)驗(yàn)教訓(xùn)進(jìn)行了深入的分析。其中，“HTTP不是RPC”、“HTTP不是一種傳輸協(xié)議”兩部分值得讀者反復(fù)閱讀。時至13年之后的今日，對于HTTP協(xié)議的誤解仍然廣泛存在。以上簡要介紹了Fielding博士論文中的內(nèi)容。為了幫助讀者仔細(xì)閱讀Fielding的博士論文，筆者整理了一套Fielding博士論文的導(dǎo)讀，將在本專欄后續(xù)文章中載出。RES

19、T詳解REST究竟是什么？因?yàn)镽EST的內(nèi)涵非常豐富，所以很難用一兩句話解釋清楚這個問題。首先，REST是Web自身的架構(gòu)風(fēng)格。REST也是Web之所以取得成功的技術(shù)架構(gòu)方面因素的總結(jié)。REST是世界上最成功的分布式應(yīng)用架構(gòu)風(fēng)格（成功案例：Web，還不夠嗎？）。它是為 運(yùn)行在互聯(lián)網(wǎng)環(huán)境 的 分布式 超媒體系統(tǒng)量身定制的?；ヂ?lián)網(wǎng)環(huán)境與企業(yè)內(nèi)網(wǎng)環(huán)境有非常大的差別，最主要的差別是兩個方面：· 可伸縮性需求無法控制：并發(fā)訪問量可能會暴漲，也可能會暴跌。· 安全性需求無法控制：無法控制客戶端發(fā)來的請求的格式，很可能會是惡意的請求。而所謂的“超媒體系統(tǒng)”，即，使用了超文本的系統(tǒng)。可以把

20、“超媒體”理解為超文本+媒體內(nèi)容。REST是HTTP/1.1協(xié)議等Web規(guī)范的設(shè)計指導(dǎo)原則，HTTP/1.1協(xié)議正是為實(shí)現(xiàn)REST風(fēng)格的架構(gòu)而設(shè)計的。新的Web規(guī)范，其設(shè)計必須符合REST的要求，否則整個Web的體系架構(gòu)會因?yàn)橐雵?yán)重矛盾而崩潰。這句話不是危言聳聽，做個類比，假如蘇州市政府同意在市區(qū)著名園林的附近大型土木，建造大量具有后現(xiàn)代風(fēng)格的摩天大樓，那么不久之后世界聞名的蘇州園林美景將不復(fù)存在。上述這些關(guān)于“REST是什么”的描述，可以總結(jié)為一句話：REST是所有Web應(yīng)用都應(yīng)該遵守的架構(gòu)設(shè)計指導(dǎo)原則。當(dāng)然，REST并不是法律，違反了REST的指導(dǎo)原則，仍然能夠?qū)崿F(xiàn)應(yīng)用的功能。但是違反了

21、REST的指導(dǎo)原則，會付出很多代價，特別是對于大流量的網(wǎng)站而言。要深入理解REST，需要理解REST的五個關(guān)鍵詞：1. 資源（Resource） 2. 資源的表述（Representation） 3. 狀態(tài)轉(zhuǎn)移（State Transfer） 4. 統(tǒng)一接口（Uniform Interface） 5. 超文本驅(qū)動（Hypertext Driven） 什么是資源？資源是一種看待服務(wù)器的方式，即，將服務(wù)器看作是由很多離散的資源組成。每個資源是服務(wù)器上一個可命名的抽象概念。因?yàn)橘Y源是一個抽象的概念，所以它不僅僅能代表服務(wù)器文件系統(tǒng)中的一個文件、數(shù)據(jù)庫中的一張表等等具體的東西，可以將資源設(shè)計的要多抽象

22、有多抽象，只要想象力允許而且客戶端應(yīng)用開發(fā)者能夠理解。與面向?qū)ο笤O(shè)計類似，資源是以名詞為核心來組織的，首先關(guān)注的是名詞。一個資源可以由一個或多個URI來標(biāo)識。URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應(yīng)用，可以通過資源的URI與其進(jìn)行交互。什么是資源的表述？資源的表述是一段對于資源在某個特定時刻的狀態(tài)的描述?？梢栽诳蛻舳?服務(wù)器端之間轉(zhuǎn)移（交換）。資源的表述可以有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。資源的表述格式可以通過協(xié)商機(jī)制來確定。請求-響應(yīng)方向的表述通常使用不同的格式。什么是狀態(tài)轉(zhuǎn)移？狀態(tài)轉(zhuǎn)移（state transfer

23、）與狀態(tài)機(jī)中的狀態(tài)遷移（state transition）的含義是不同的。狀態(tài)轉(zhuǎn)移說的是：在客戶端與服務(wù)器端之間轉(zhuǎn)移（transfer）代表資源狀態(tài)的表述。通過轉(zhuǎn)移與操作資源的表述，來間接實(shí)現(xiàn)操作資源的目的。什么是統(tǒng)一接口？REST要求，必須通過統(tǒng)一的接口來對資源執(zhí)行各種操作。對于每個資源只能執(zhí)行一組有限的操作。以HTTP/1.1協(xié)議為例，HTTP/1.1協(xié)議定義了一個操作資源的統(tǒng)一接口，主要包括以下內(nèi)容：· 7個HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS· HTTP頭信息（可自定義）· HTTP響應(yīng)狀態(tài)代碼（可自定

24、義）· 一套標(biāo)準(zhǔn)的內(nèi)容協(xié)商機(jī)制· 一套標(biāo)準(zhǔn)的緩存機(jī)制· 一套標(biāo)準(zhǔn)的客戶端身份認(rèn)證機(jī)制REST還要求，對于資源執(zhí)行的操作，其操作語義必須由HTTP消息體之前的部分完全表達(dá)，不能將操作語義封裝在HTTP消息體內(nèi)部。這樣做是為了提高交互的可見性，以便于通信鏈的中間組件實(shí)現(xiàn)緩存、安全審計等等功能。什么是超文本驅(qū)動？“超文本驅(qū)動”又名“將超媒體作為應(yīng)用狀態(tài)的引擎”（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫為HATEOAS）。將Web應(yīng)用看作是一個由很多狀態(tài)（應(yīng)用狀態(tài)）組成的有限狀

25、態(tài)機(jī)。資源之間通過超鏈接相互關(guān)聯(lián)，超鏈接既代表資源之間的關(guān)系，也代表可執(zhí)行的狀態(tài)遷移。在超媒體之中不僅僅包含數(shù)據(jù)，還包含了狀態(tài)遷移的語義。以超媒體作為引擎，驅(qū)動Web應(yīng)用的狀態(tài)遷移。通過超媒體暴露出服務(wù)器所提供的資源，服務(wù)器提供了哪些資源是在運(yùn)行時通過解析超媒體發(fā)現(xiàn)的，而不是事先定義的。從面向服務(wù)的角度看，超媒體定義了服務(wù)器所提供服務(wù)的協(xié)議。客戶端應(yīng)該依賴的是超媒體的狀態(tài)遷移語義，而不應(yīng)該對于是否存在某個URI或URI的某種特殊構(gòu)造方式作出假設(shè)。一切都有可能變化，只有超媒體的狀態(tài)遷移語義能夠長期保持穩(wěn)定。一旦讀者理解了上述REST的五個關(guān)鍵詞，就很容易理解REST風(fēng)格的架構(gòu)所具有的6個的主要特

26、征：· 面向資源（Resource Oriented）· 可尋址（Addressability）· 連通性（Connectedness）· 無狀態(tài)（Statelessness）· 統(tǒng)一接口（Uniform Interface）· 超文本驅(qū)動（Hypertext Driven）這6個特征是REST架構(gòu)設(shè)計優(yōu)秀程度的判斷標(biāo)準(zhǔn)。其中，面向資源是REST最明顯的特征，即，REST架構(gòu)設(shè)計是以資源抽象為核心展開的。可尋址說的是：每一個資源在Web之上都有自己的地址。連通性說的是：應(yīng)該盡量避免設(shè)計孤立的資源，除了設(shè)計資源本身，還需要設(shè)計資源之間的

27、關(guān)聯(lián)關(guān)系，并且通過超鏈接將資源關(guān)聯(lián)起來。無狀態(tài)、統(tǒng)一接口是REST的兩種架構(gòu)約束，超文本驅(qū)動是REST的一個關(guān)鍵詞，在前面都已經(jīng)解釋過，就不再贅述了。從架構(gòu)風(fēng)格的抽象高度來看，常見的分布式應(yīng)用架構(gòu)風(fēng)格有三種：· 分布式對象（Distributed Objects，簡稱DO） 架構(gòu)實(shí)例有CORBA/RMI/EJB/DCOM/.NET Remoting等等· 遠(yuǎn)程過程調(diào)用（Remote Procedure Call，簡稱RPC） 架構(gòu)實(shí)例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等· 表述性狀態(tài)轉(zhuǎn)移（Representational St

28、ate Transfer，簡稱REST） 架構(gòu)實(shí)例有HTTP/WebDAVDO與RPC這兩種架構(gòu)風(fēng)格在企業(yè)應(yīng)用中非常普遍，而REST則是Web應(yīng)用的架構(gòu)風(fēng)格，它們之間有非常大的差別。REST與DO的差別在于：· REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在不同的編程語言中，對象的定義有很大差別，所以DO風(fēng)格的架構(gòu)通常都是與某種編程語言綁定的?？缯Z言交互即使能實(shí)現(xiàn)，實(shí)現(xiàn)起來也會非常復(fù)雜。而REST中的資源，則完全中立于開發(fā)平臺與編程語言，可以使用任何編程語言來實(shí)現(xiàn)。· DO中沒有統(tǒng)一接口的概念。不同的API，接口設(shè)計風(fēng)格可以完全不同。DO也不支持操作語

29、義對于中間組件的可見性。· DO中沒有使用超文本，響應(yīng)的內(nèi)容中只包含對象本身。REST使用了超文本，可以實(shí)現(xiàn)更大粒度的交互，交互的效率比DO更高。· REST支持?jǐn)?shù)據(jù)流與管道，DO不支持?jǐn)?shù)據(jù)流與管道。· DO風(fēng)格通常會帶來客戶端與服務(wù)器端的緊耦合。在三種架構(gòu)風(fēng)格之中，DO風(fēng)格的耦合度是最大的，而REST的風(fēng)格耦合度是最小的。REST松耦合的源泉來自于統(tǒng)一接口+超文本驅(qū)動。REST與RPC的差別在于：· REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風(fēng)格的架構(gòu)建模是以名詞為核心的，RPC風(fēng)格的架構(gòu)建模是以動詞為核心的。簡單類比一下，REST是面向?qū)ο缶幊蹋琑PC則是面向過程編程。· RPC中沒有統(tǒng)一接口的概念。不同的API，接口設(shè)計風(fēng)格可以完全不同。RPC也不支持操作語義對于中間組件的可見性。· RPC中沒有使用超文本，響應(yīng)的內(nèi)容中只包含消息本身。REST使用了超文本，可以實(shí)現(xiàn)更大粒度的交互，交互的效率比RPC更高。· REST支持?jǐn)?shù)據(jù)流與管道，RPC不支持?jǐn)?shù)據(jù)流與管道。· 因?yàn)槭褂昧似脚_中立的消息，RPC風(fēng)格的耦合度比DO風(fēng)格要小一些，但是RPC風(fēng)格也常常會帶來客戶端與服務(wù)器端的緊耦合。支持統(tǒng)一接口+超文本驅(qū)動的REST風(fēng)