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

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

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

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

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

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

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

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

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

9、的這套理論 框架，最初是以備忘錄的形式在 專家組成員之間交流，除了 IETF/W3C的專家圈子，并沒(méi)有在外界廣泛流傳。 Fielding 在完成 HTTP/1.1 協(xié)議的設(shè)計(jì)工作之后，回到了加州大學(xué)歐 文分校繼 續(xù)攻讀自己的博士學(xué)位。第二年（ 2000年）在他的博士學(xué)位論文Architectural Styles and the Design of Network-based Software Architectures 中， Fielding 更為系統(tǒng)、嚴(yán)謹(jǐn)?shù)仃U述了這套理論框架，并且 使 用這套理論框架推導(dǎo)出了一種新的架構(gòu)風(fēng)格，并且為這種架構(gòu)風(fēng)格取了一個(gè) 令 人輕松愉快的名字“ REST”

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

11、eb開(kāi)發(fā)技術(shù)社區(qū)掀起了一場(chǎng)重歸Web架構(gòu)設(shè)計(jì)本源 的運(yùn)動(dòng)，REST架構(gòu)風(fēng)格得到了越來(lái)越多的關(guān)注。在 2007年1月，支持REST開(kāi) 發(fā)的Ruby on Rails 1.2 版正式發(fā)布，并且將支持REST開(kāi)發(fā)作為Rails未來(lái)發(fā) 展中的優(yōu)先內(nèi)容。Ruby on Rails的創(chuàng)始人DHH做了一個(gè)名為“ World of Resources”的精彩演講，DHH在 Web開(kāi)發(fā)技術(shù)社區(qū)中的強(qiáng)大影響力，使得 REST 一下子處在 Web開(kāi)發(fā)技術(shù)舞臺(tái)的聚光燈之下。今天，各種流行的 Web開(kāi)發(fā)框架，幾乎沒(méi)有不支持REST開(kāi)發(fā)的了。大多數(shù) Web 開(kāi)發(fā)者都是通過(guò)閱讀某種 REST開(kāi)發(fā)框架的文檔，以及通過(guò)一些例子

12、代碼來(lái)學(xué)習(xí) REST開(kāi)發(fā)的。然而，通過(guò)例子代碼來(lái)學(xué)習(xí)REST有非常大的局限性。因?yàn)?REST 并不是一種具體的技術(shù)，也不是一種具體的規(guī)范，REST其實(shí)是一種內(nèi)涵非常豐富的架構(gòu)風(fēng)格。通過(guò)例子代碼來(lái)學(xué)習(xí) REST除了學(xué)習(xí)到一種有趣的Web開(kāi)發(fā)技 術(shù)之外，并不能全面深入的理解 REST究竟是什么。甚至還會(huì)誤以為這些簡(jiǎn)單的 例子代碼就是REST本身，REST不過(guò)是一種簡(jiǎn)單的Web開(kāi)發(fā)技術(shù)而已。就像盲人 摸象一樣，有的人摸到了象鼻子、有的人摸到了象耳朵、有的人摸到了象 腿、 有的人摸到了象尾巴。他們都堅(jiān)信自己感覺(jué)到的大象，才是最真實(shí)的大象， 而 其他人的感覺(jué)都是錯(cuò)誤的。對(duì)于不理解REST的 Web開(kāi)發(fā)者

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

14、of Networkbased Software Architectures 的博士論文（中文版名為架構(gòu)風(fēng)格與基于網(wǎng) 絡(luò)的軟件架構(gòu)設(shè)計(jì)）中，提出了一整套基于網(wǎng)絡(luò)的軟件（即所謂的“分布 式 應(yīng)用”）的設(shè)計(jì)方法，值得所有分布式應(yīng)用的開(kāi)發(fā)者仔細(xì)閱讀、深入體會(huì)。在論文的前三章中， Fielding 在批判性繼承前人研究成果的基礎(chǔ)上，建立起來(lái) 一整套研究與評(píng)價(jià)軟件架構(gòu)的方法論。這套方法論的核心是“架構(gòu)風(fēng)格”這 個(gè) 概念。架構(gòu)風(fēng)格是一種研究與評(píng)價(jià)軟件架構(gòu)設(shè)計(jì)的方法，它是比架構(gòu)更加抽 象的概念。一種架構(gòu)風(fēng)格是由一組相互協(xié)作的架構(gòu)約束來(lái)定義的。架構(gòu)約束是指軟件的運(yùn)行環(huán)境施加在架構(gòu)設(shè)計(jì)之上的約束。在論文的第四章

15、中，F(xiàn)ielding研究了 Web這樣一個(gè)分布式系統(tǒng)對(duì)于軟件架構(gòu)設(shè) 計(jì)提出了哪些需求。在第五章中，F(xiàn)ielding將第四章 Web提出的需求具體化為一些架構(gòu)約束，通過(guò)逐步添加各種架構(gòu)約束，推導(dǎo)出來(lái)了REST這種新的架構(gòu)風(fēng)格。REST架構(gòu)風(fēng)格的推導(dǎo)過(guò)程如下圖所示：圖1： REST所繼承的架構(gòu)風(fēng)格約束(原圖可在這里下載)vf sbJcmotile心占旳Shared曲VW地在圖1中，每一個(gè)橢圓形里面的縮寫(xiě)詞代表了一種架構(gòu)風(fēng)格，而每一個(gè)箭頭邊的單詞代表了一種架構(gòu)約束。REST架構(gòu)風(fēng)格最重要的架構(gòu)約束有6個(gè):客戶-服務(wù)器(Client-Server )通信只能由客戶端單方面發(fā)起，表現(xiàn)為請(qǐng)求-響應(yīng)的形式。

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

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

18、求（a）被發(fā)送到一個(gè)本地代理，代理隨后訪 問(wèn)一個(gè)通過(guò)DNSS找發(fā)現(xiàn)的緩存網(wǎng)關(guān)，該網(wǎng)關(guān)將這個(gè)請(qǐng)求轉(zhuǎn)發(fā)到一個(gè)能夠滿足該請(qǐng)求的來(lái)源服務(wù)器，服務(wù)器的內(nèi)部資源由一個(gè)封裝過(guò)的對(duì)象請(qǐng)求代理（object request broker）架構(gòu)來(lái)定義。請(qǐng)求（b）直接發(fā)送到一個(gè)來(lái)源服務(wù) 器，它能夠通過(guò)自己的緩存來(lái)滿足這個(gè)請(qǐng)求。請(qǐng)求（c）被發(fā)送到一個(gè)代理，它能夠直接訪問(wèn) WAIS（ 種與Web架構(gòu)分離的信息服務(wù)），并將 WAIS的響應(yīng)翻 譯為一種通用的連接器接口能夠識(shí)別的格式。每一個(gè)組件只知道與它們自己的客戶端或服務(wù)器連接器的交互；整個(gè)過(guò)程拓?fù)涫俏覀兊囊晥D的產(chǎn)物。通過(guò)比較圖2與圖3,讀者不難發(fā)現(xiàn)這兩張圖中的架構(gòu)是 高

19、度一致的。對(duì)于 HTTP/1.1協(xié)議為何要設(shè)計(jì)成這個(gè)樣子，讀者想必已經(jīng)有所領(lǐng)悟。在論文的第六章中，F(xiàn)ielding對(duì)于到2000年為止在Web基礎(chǔ)架構(gòu)協(xié)議的設(shè)計(jì) 與 開(kāi)發(fā)方面的一些經(jīng)驗(yàn)教訓(xùn)進(jìn)行了深入的分析。其中，“HTTF不是RPC、“HTTP不是一種傳輸協(xié)議”兩部分值得讀者反復(fù)閱讀。時(shí)至13年之后的今日，對(duì)于HTTP協(xié)議的誤解仍然廣泛存在。以上簡(jiǎn)要介紹了 Fielding博士論文中的內(nèi)容。為了幫助讀者仔細(xì)閱讀 Fielding的博士論文，筆者整理了一套Fielding博士論文的導(dǎo)讀，將在本專 欄后續(xù)文章中載出。REST羊解REST究竟是什么？因?yàn)镽EST的內(nèi)涵非常豐富，所以很難用一兩句話解釋

20、清楚 這個(gè)問(wèn)題。首先，REST是 Web自身的架構(gòu)風(fēng)格。RES也是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)境有非常大的差別，最主要的差別是兩個(gè)方面：可伸縮性需求無(wú)法控制：并發(fā)訪問(wèn)量可能會(huì)暴漲，也可能會(huì)暴跌。安全性需求無(wú)法控制：無(wú)法控制客戶端發(fā)來(lái)的請(qǐng)求的格式，很可能會(huì)是惡意的請(qǐng)求。而所謂的“超媒體系統(tǒng)”，即，使用了超文本的系統(tǒng)?？梢园选俺襟w”理解為超文本+媒體內(nèi)容。REST是 HTTP/1.1協(xié)議等 Web規(guī)范的設(shè)計(jì)指導(dǎo)原則，H

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

22、需要理解REST勺五個(gè)關(guān)鍵詞:1. 資源(Resource)2. 資源的表述(Representation ) 狀3. 態(tài)轉(zhuǎn)移(State Transfer ) 統(tǒng)一4. 接口( Un iform In terface) 超文5. 本驅(qū)動(dòng)(Hypertext Driven )什么是資源？所體應(yīng)首資源是一種看待服務(wù)器的方式，即，將服務(wù)器看作是由很多離散的資源組成 每個(gè)資源是服務(wù)器上一個(gè)可命名的抽象概念。因?yàn)橘Y源是一個(gè)抽象的概念， 以它不僅僅能代表服務(wù)器文件系統(tǒng)中的一個(gè)文件、數(shù)據(jù)庫(kù)中的一張表等等具 的東西，可以將資源設(shè)計(jì)的要多抽象有多抽象，只要想象力允許而且客戶端 用開(kāi)發(fā)者能夠理解。與面向?qū)ο笤O(shè)計(jì)

23、類似，資源是以名詞為核心來(lái)組織的， 先關(guān)注的是名詞。一個(gè)資源可以由一個(gè)或多個(gè) URI來(lái)標(biāo)識(shí)。URI既是資源的名 稱，也是資源在 Web上的地址。對(duì)某個(gè)資源感興趣的客戶端應(yīng)用，可以通過(guò)資 源的URI與其進(jìn)行交互。什么是資源的表述？資源的表述是一段對(duì)于資源在某個(gè)特定時(shí)刻的狀態(tài)的描述?？梢栽诳蛻舳?-服務(wù) 器端之間轉(zhuǎn)移(交換)。資源的表述可以有多種格式，例如 HTML/XML/JSO純 文本/圖片/視頻/音頻等等。資源的表 述格式可以通過(guò)協(xié)商機(jī)制來(lái)確定。請(qǐng)求 - 響應(yīng)方向的表述通常使用不同的格式。什么是狀態(tài)轉(zhuǎn)移？狀態(tài)轉(zhuǎn)移(state transfer )與狀態(tài)機(jī)中的狀態(tài)遷移(state transi

24、tion )的 含義是不同的。狀態(tài)轉(zhuǎn)移說(shuō)的是：在客戶端與服務(wù)器端之間轉(zhuǎn)移(transfer )代表資源狀態(tài)的表述。通過(guò)轉(zhuǎn)移與操作資源的表述，來(lái)間接實(shí)現(xiàn)操作資源的目的。什么是統(tǒng)一接口？RESTg求，必須通 過(guò)統(tǒng)一的接口來(lái)對(duì)資源執(zhí)行各種操作。對(duì)于每個(gè)資源只能執(zhí) 行一組有限的操作。以 HTTP/1.1協(xié)議為例，HTTP/1.1協(xié)議定義了一個(gè)操作資 源的統(tǒng)一接口，主要包括以下內(nèi)容：7 個(gè) HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONSHTTP頭信息(可自定義)HTTH向應(yīng)狀態(tài)代碼(可自定義)一套標(biāo)準(zhǔn)的內(nèi)容協(xié)商機(jī)制一套標(biāo)準(zhǔn)的緩存機(jī)制一套標(biāo)準(zhǔn)的客戶端身份認(rèn)證機(jī)制

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

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

27、通性(Connectedness)無(wú)狀態(tài)(Statelessness )統(tǒng)一接口(Un iform In terface )超文本驅(qū)動(dòng)(Hypertext Driven )這6個(gè)特征是REST架構(gòu)設(shè)計(jì)優(yōu)秀程度的判斷標(biāo)準(zhǔn)。其中，面向資源是REST最明顯的特征，即，REST架構(gòu)設(shè)計(jì)是以資源抽象為核心展開(kāi)的?？蓪ぶ氛f(shuō)的是： 每一個(gè)資源在 Web之上都有自己的地址。連通性說(shuō)的是：應(yīng)該盡量避免設(shè)計(jì)孤立的資源，除了設(shè)計(jì)資源本身，還需要設(shè)計(jì)資源之間的關(guān)聯(lián)關(guān)系，并且通過(guò)超鏈接將資源關(guān)聯(lián)起來(lái)。無(wú)狀態(tài)、統(tǒng)一接口是REST勺兩種架構(gòu)約束，超文本驅(qū)動(dòng)是REST的個(gè)關(guān)鍵詞，在前面都已經(jīng) 解釋過(guò)，就不再贅述了。從架構(gòu)風(fēng)格

28、的抽象高度來(lái)看，常見(jiàn)的分布式應(yīng)用架構(gòu)風(fēng)格有三種:分布式對(duì)象(Distributed Objects，簡(jiǎn)稱 DO架構(gòu)實(shí)例有 CORBA/RMI/EJB/DCOM/.NETemoting 等等遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call ,簡(jiǎn)稱RPC架構(gòu)實(shí)例有 SOAP/XML-RPC/Hessian/FlashAMF/DW等等表述性狀態(tài)轉(zhuǎn)移（Representational State Transfer ，簡(jiǎn)稱 REST架構(gòu)實(shí)例有HTTP/WebDAVDC與 RPC這兩種架構(gòu)風(fēng)格在企業(yè)應(yīng)用中非常普遍，而 REST則是Web應(yīng)用的架 構(gòu)風(fēng)格，它們之間有非常大的差別。REST與 DO的差

29、別在于：REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對(duì)象。在 不同的編程語(yǔ)言中，對(duì)象的定義有很大差別，所以DO風(fēng)格的架構(gòu)通常都是與某種編程語(yǔ)言綁定的?？缯Z(yǔ)言交互即使能實(shí)現(xiàn)，實(shí)現(xiàn)起來(lái)也會(huì)非常 復(fù)雜。而REST中的資源，貝皖全中立于開(kāi)發(fā)平臺(tái)與編程語(yǔ)言，可以使用 任何編程語(yǔ)言來(lái)實(shí)現(xiàn)。DO中沒(méi)有統(tǒng)一接口的概念。不同的API，接口設(shè)計(jì)風(fēng)格可以完全不同。DO也不支持操作語(yǔ) 義對(duì)于中間組件的可見(jiàn)性。DO中沒(méi)有使用超文 本，響應(yīng)的內(nèi)容中只包含對(duì)象本身。REST使用了超文本，可以實(shí)現(xiàn)更大粒度的交互，交互的效率比 DO更高。REST支持?jǐn)?shù)據(jù)流與管道，DO不支持?jǐn)?shù)據(jù)流與管道。DO風(fēng)格通常會(huì)帶來(lái) 客戶

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