理解本真的REST架構(gòu)風(fēng)格重點(diǎn)

1、理解本真的REST架構(gòu)風(fēng)格本文是“深入探索REST”專欄系列深度內(nèi)容中的第二篇，它將帶您領(lǐng)略REST架構(gòu)的起源、與Web的關(guān)系、REST架構(gòu)的本質(zhì)及特性，以及REST架構(gòu)與其他架構(gòu)風(fēng)格之間的比較。引子在移動(dòng)互聯(lián)網(wǎng)、云計(jì)算迅猛發(fā)展的今天，作為一名Web開發(fā)者，如果您還沒聽說過“REST”這個(gè)buzzword，顯然已經(jīng)落伍了?？鋸堻c(diǎn)說，甚至“出了門都不好意思跟別人打招呼”。盡管如此，對(duì)于REST這個(gè)泊來品的理解，大多數(shù)人（包括一些資深的架構(gòu)師）仍然停留在“盲人摸象”的階段。常常聽到各種各樣關(guān)于REST的說法，例如：有人說：“我們這套新的API決定不用Web Service（SOAP+WSDL），而

2、是直接使用HTTP+JSON，也就是用RESTful的方式來開發(fā)?！?不用SOAP，甚至也不用XML，就自動(dòng)變成了RESTful了。還有人認(rèn)為：REST與傳統(tǒng)的Web Service其實(shí)沒有本質(zhì)區(qū)別，只是對(duì)于URI的構(gòu)造方式提出了更多要求，而這些要求Web Service完全都可以實(shí)現(xiàn)。潛臺(tái)詞是：既生瑜，何生亮。Web Service已經(jīng)足夠好了，干嘛還要再折騰什么REST。這些對(duì)于REST的不同說法，果真如此嗎？REST究竟是什么？是一種新的技術(shù)、一種新的架構(gòu)、還是一種新的規(guī)范？對(duì)于這些問題筆者先不解答，為了深入理解REST是什么，我們需要回顧一下Web發(fā)展的最初年代，從源頭上講講REST是

3、怎么得來的。Web技術(shù)發(fā)展與REST的由來Web（萬維網(wǎng)World Wide Web的簡稱）是個(gè)包羅萬象的萬花筒，不同的人從不同的角度觀察，對(duì)于Web究竟是什么會(huì)得出大不相同的觀點(diǎn)。作為Web開發(fā)者，我們需要從技術(shù)上來理解Web。從技術(shù)架構(gòu)層面上看，Web的技術(shù)架構(gòu)包括了四個(gè)基石：· URI· HTTP· HyperText（除了HTML外，也可以是帶有超鏈接的XML或JSON）· MIME這四個(gè)基石相互支撐，促使Web這座宏偉的大廈以幾何級(jí)數(shù)的速度發(fā)展了起來。在這四個(gè)基石之上，Web開發(fā)技術(shù)的發(fā)展可以粗略劃分成以下幾個(gè)階段：1. 靜態(tài)內(nèi)容階段：在這個(gè)最

4、初的階段，使用Web的主要是一些研究機(jī)構(gòu)。Web由大量的靜態(tài)HTML文檔組成，其中大多是一些學(xué)術(shù)論文。Web服務(wù)器可以被看作是支持超文本的共享文件服務(wù)器。2. CGI程序階段：在這個(gè)階段，Web服務(wù)器增加了一些編程API。通過這些API編寫的應(yīng)用程序，可以向客戶端提供一些動(dòng)態(tài)變化的內(nèi)容。Web服務(wù)器與應(yīng)用程序之間的通信，通過CGI（Common Gateway Interface）協(xié)議完成，應(yīng)用程序被稱作CGI程序。3. 腳本語言階段：在這個(gè)階段，服務(wù)器端出現(xiàn)了ASP、PHP、JSP、ColdFusion等支持session的腳本語言技術(shù)，瀏覽器端出現(xiàn)了Java Applet、JavaScri

5、pt等技術(shù)。使用這些技術(shù)，可以提供更加豐富的動(dòng)態(tài)內(nèi)容。4. 瘦客戶端應(yīng)用階段：在這個(gè)階段，在服務(wù)器端出現(xiàn)了獨(dú)立于Web服務(wù)器的應(yīng)用服務(wù)器。同時(shí)出現(xiàn)了Web MVC開發(fā)模式，各種Web MVC開發(fā)框架逐漸流行，并且占據(jù)了統(tǒng)治地位?；谶@些框架開發(fā)的Web應(yīng)用，通常都是瘦客戶端應(yīng)用，因?yàn)樗鼈兪窃诜?wù)器端生成全部的動(dòng)態(tài)內(nèi)容。5. RIA應(yīng)用階段：在這個(gè)階段，出現(xiàn)了多種RIA（Rich Internet Application）技術(shù)，大幅改善了Web應(yīng)用的用戶體驗(yàn)。應(yīng)用最為廣泛的RIA技術(shù)是DHTML+Ajax。Ajax技術(shù)支持在不刷新頁面的情況下動(dòng)態(tài)更新頁面中的局部內(nèi)容。同時(shí)誕生了大量的Web前端D

6、HTML開發(fā)庫，例如Prototype、Dojo、ExtJS、jQuery/jQuery UI等等，很多開發(fā)庫都支持單頁面應(yīng)用（Single Page Application）的開發(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)用開發(fā)技術(shù)。除了Android、iOS、Windows Phone等操作系統(tǒng)平臺(tái)原生的開發(fā)技術(shù)之外，基于HTML5的開發(fā)技術(shù)也變得非常流行。從上述Web開發(fā)技術(shù)的發(fā)展過程看，Web從最初其設(shè)計(jì)者所構(gòu)思的主要

7、支持靜態(tài)文檔的階段，逐漸變得越來越動(dòng)態(tài)化。Web應(yīng)用的交互模式，變得越來越復(fù)雜：從靜態(tài)文檔發(fā)展到以內(nèi)容為主的門戶網(wǎng)站、電子商務(wù)網(wǎng)站、搜索引擎、社交網(wǎng)站，再到以娛樂為主的大型多人在線游戲、手機(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è)計(jì)新版本的HTTP協(xié)議。在HTTP/1.0協(xié)議專家組之中，有一位年輕人脫穎而出，顯示出了不凡的洞察力，后來他成為了HTTP/1.1協(xié)議專家組的負(fù)責(zé)人。這位年輕人就是Apache HTTP服務(wù)器的核心開發(fā)者Roy F

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

9、為有修訂的必要。用來指導(dǎo)HTTP/1.1協(xié)議設(shè)計(jì)的這套理論框架，最初是以備忘錄的形式在專家組成員之間交流，除了IETF/W3C的專家圈子，并沒有在外界廣泛流傳。Fielding在完成HTTP/1.1協(xié)議的設(shè)計(jì)工作之后，回到了加州大學(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)格取了一個(gè)令人輕松愉快的名字“

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

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

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

13、Web開發(fā)者想要深入理解REST是什么，就很難避開Fielding的這篇博士論文。筆者在本文中對(duì)于REST是什么的介紹，也是基于Fielding的博士論文的。盡管如此，筆者強(qiáng)烈建議本文的讀者親自去通讀一下Fielding的博士論文，就像想要了解孔子的思想應(yīng)該直接去讀論語等著作，而不是首先去讀其他人的轉(zhuǎn)述一樣。筆者在本文中也僅僅是努力不做一個(gè)把經(jīng)書念錯(cuò)了的歪嘴和尚而已。那么，下面我們言歸正傳。在Fielding的這篇名為Architectural Styles and the Design of Network-based Software Architectures的博士論文（中文版名為架構(gòu)風(fēng)

14、格與基于網(wǎng)絡(luò)的軟件架構(gòu)設(shè)計(jì)）中，提出了一整套基于網(wǎng)絡(luò)的軟件（即所謂的“分布式應(yīng)用”）的設(shè)計(jì)方法，值得所有分布式應(yīng)用的開發(fā)者仔細(xì)閱讀、深入體會(huì)。在論文的前三章中，F(xiàn)ielding在批判性繼承前人研究成果的基礎(chǔ)上，建立起來一整套研究和評(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)約束來定義的。架構(gòu)約束是指軟件的運(yùn)行環(huán)境施加在架構(gòu)設(shè)計(jì)之上的約束。在論文的第四章中，F(xiàn)ielding研究了Web這樣一個(gè)分布式系統(tǒng)對(duì)于軟件架構(gòu)設(shè)計(jì)提出了哪些需求。在第五章中，F(xiàn)ielding將第四章Web

15、提出的需求具體化為一些架構(gòu)約束，通過逐步添加各種架構(gòu)約束，推導(dǎo)出來了REST這種新的架構(gòu)風(fēng)格。REST架構(gòu)風(fēng)格的推導(dǎo)過程如下圖所示：圖1：REST所繼承的架構(gòu)風(fēng)格約束（原圖可在這里下載）在圖1中，每一個(gè)橢圓形里面的縮寫詞代表了一種架構(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)的形式。· 無狀態(tài)（Stateless）通信的會(huì)話狀態(tài)（Session State）應(yīng)該全部由客戶端負(fù)責(zé)維護(hù)。· 緩存（Cache）響應(yīng)內(nèi)容可以在通信鏈的某處被

16、緩存，以改善網(wǎng)絡(luò)效率。· 統(tǒng)一接口（Uniform Interface）通信鏈的組件之間通過統(tǒng)一的接口相互通信，以提高交互的可見性。· 分層系統(tǒng)（Layered System）通過限制組件的行為（即，每個(gè)組件只能“看到”與其交互的緊鄰層），將架構(gòu)分解為若干等級(jí)的層。· 按需代碼（Code-On-Demand，可選）支持通過下載并執(zhí)行一些代碼（例如Java Applet、Flash或JavaScript），對(duì)客戶端的功能進(jìn)行擴(kuò)展。在論文中推導(dǎo)出的REST架構(gòu)風(fēng)格如下圖所示：圖2：REST架構(gòu)風(fēng)格（原圖可在這里下載） 而HTTP/1.1協(xié)議作為一種REST架

17、構(gòu)風(fēng)格的架構(gòu)實(shí)例，其架構(gòu)如下圖所示：圖3：一個(gè)基于REST的架構(gòu)的過程視圖（原圖可在這里下載）用戶代理處在三個(gè)并行交互（a、b和c）的中間。用戶代理的客戶端連接器緩存無法滿足請(qǐng)求，因此它根據(jù)每個(gè)資源標(biāo)識(shí)符的屬性和客戶端連接器的配置，將每個(gè)請(qǐng)求路由到資源的來源。請(qǐng)求（a）被發(fā)送到一個(gè)本地代理，代理隨后訪問一個(gè)通過DNS查找發(fā)現(xiàn)的緩存網(wǎng)關(guān)，該網(wǎng)關(guān)將這個(gè)請(qǐng)求轉(zhuǎn)發(fā)到一個(gè)能夠滿足該請(qǐng)求的來源服務(wù)器，服務(wù)器的內(nèi)部資源由一個(gè)封裝過的對(duì)象請(qǐng)求代理（object request broker）架構(gòu)來定義。請(qǐng)求（b）直接發(fā)送到一個(gè)來源服務(wù)器，它能夠通過自己的緩存來滿足這個(gè)請(qǐng)求。請(qǐng)求（c）被發(fā)送到一個(gè)代理，它能夠直

18、接訪問WAIS（一種與Web架構(gòu)分離的信息服務(wù)），并將WAIS的響應(yīng)翻譯為一種通用的連接器接口能夠識(shí)別的格式。每一個(gè)組件只知道與它們自己的客戶端或服務(wù)器連接器的交互；整個(gè)過程拓?fù)涫俏覀兊囊晥D的產(chǎn)物。通過比較圖2和圖3，讀者不難發(fā)現(xiàn)這兩張圖中的架構(gòu)是高度一致的。對(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ì)和開發(fā)方面的一些經(jīng)驗(yàn)教訓(xùn)進(jìn)行了深入的分析。其中，“HTTP不是RPC”、“HTTP不是一種傳輸協(xié)議”兩部分值得讀者反復(fù)閱讀。時(shí)至13年之后的今日，對(duì)于HTTP協(xié)議的誤解仍然廣泛存在。以上簡要介

19、紹了Fielding博士論文中的內(nèi)容。為了幫助讀者仔細(xì)閱讀Fielding的博士論文，筆者整理了一套Fielding博士論文的導(dǎo)讀，將在本專欄后續(xù)文章中載出。REST詳解REST究竟是什么？因?yàn)镽EST的內(nèi)涵非常豐富，所以很難用一兩句話解釋清楚這個(gè)問題。首先，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)境有非常大的差別，最主要的差別是兩個(gè)方面：· 可伸縮性需求無法控制：并發(fā)訪問量可能

20、會(huì)暴漲，也可能會(huì)暴跌。· 安全性需求無法控制：無法控制客戶端發(fā)來的請(qǐng)求的格式，很可能會(huì)是惡意的請(qǐng)求。而所謂的“超媒體系統(tǒng)”，即，使用了超文本的系統(tǒng)?？梢园选俺襟w”理解為超文本+媒體內(nèi)容。REST是HTTP/1.1協(xié)議等Web規(guī)范的設(shè)計(jì)指導(dǎo)原則，HTTP/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)重矛盾而崩潰。這句話不是危言聳聽，做個(gè)類比，假如蘇州市政府同意在市區(qū)著名園林的附近大型土木，建造大量具有后現(xiàn)代風(fēng)格的摩天大樓，那么不久之后世界聞名的蘇州園林美景將不復(fù)存在。上述這些關(guān)于“REST是什么”的

21、描述，可以總結(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，需要理解REST的五個(gè)關(guān)鍵詞：1. 資源（Resource）2. 資源的表述（Representation）3. 狀態(tài)轉(zhuǎn)移（State Transfer）4. 統(tǒng)一接口（Uniform Interface）5. 超文本驅(qū)動(dòng)（Hypertext Driven）什么是資源？資源是一種看待服務(wù)器的方式，即，將服務(wù)器看作是由很多離散的資源組成。每個(gè)資源是服務(wù)

22、器上一個(gè)可命名的抽象概念。因?yàn)橘Y源是一個(gè)抽象的概念，所以它不僅僅能代表服務(wù)器文件系統(tǒng)中的一個(gè)文件、數(shù)據(jù)庫中的一張表等等具體的東西，可以將資源設(shè)計(jì)的要多抽象有多抽象，只要想象力允許而且客戶端應(yīng)用開發(fā)者能夠理解。與面向?qū)ο笤O(shè)計(jì)類似，資源是以名詞為核心來組織的，首先關(guān)注的是名詞。一個(gè)資源可以由一個(gè)或多個(gè)URI來標(biāo)識(shí)。URI既是資源的名稱，也是資源在Web上的地址。對(duì)某個(gè)資源感興趣的客戶端應(yīng)用，可以通過資源的URI與其進(jìn)行交互。什么是資源的表述？資源的表述是一段對(duì)于資源在某個(gè)特定時(shí)刻的狀態(tài)的描述?？梢栽诳蛻舳?服務(wù)器端之間轉(zhuǎn)移（交換）。資源的表述可以有多種格式，例如HTML/XML/JSON/純文本/

23、圖片/視頻/音頻等等。資源的表述格式可以通過協(xié)商機(jī)制來確定。請(qǐng)求-響應(yīng)方向的表述通常使用不同的格式。什么是狀態(tài)轉(zhuǎn)移？狀態(tài)轉(zhuǎn)移（state transfer）與狀態(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)一的接口來對(duì)資源執(zhí)行各種操作。對(duì)于每個(gè)資源只能執(zhí)行一組有限的操作。以HTTP/1.1協(xié)議為例，HTTP/1.1協(xié)議定義了一個(gè)操作資源的統(tǒng)一接口，主要包括以下內(nèi)容：· 7個(gè)HTTP方法：GE

24、T/POST/PUT/DELETE/PATCH/HEAD/OPTIONS· HTTP頭信息（可自定義）· HTTP響應(yīng)狀態(tài)代碼（可自定義）· 一套標(biāo)準(zhǔn)的內(nèi)容協(xié)商機(jī)制· 一套標(biāo)準(zhǔn)的緩存機(jī)制· 一套標(biāo)準(zhǔn)的客戶端身份認(rèn)證機(jī)制REST還要求，對(duì)于資源執(zhí)行的操作，其操作語義必須由HTTP消息體之前的部分完全表達(dá)，不能將操作語義封裝在HTTP消息體內(nèi)部。這樣做是為了提高交互的可見性，以便于通信鏈的中間組件實(shí)現(xiàn)緩存、安全審計(jì)等等功能。什么是超文本驅(qū)動(dòng)？“超文本驅(qū)動(dòng)”又名“將超媒體作為應(yīng)用狀態(tài)的引擎”（Hypermedia As The Engine Of A

25、pplication State，來自Fielding博士論文中的一句話，縮寫為HATEOAS）。將Web應(yīng)用看作是一個(gè)由很多狀態(tài)（應(yīng)用狀態(tài)）組成的有限狀態(tài)機(jī)。資源之間通過超鏈接相互關(guān)聯(lián)，超鏈接既代表資源之間的關(guān)系，也代表可執(zhí)行的狀態(tài)遷移。在超媒體之中不僅僅包含數(shù)據(jù)，還包含了狀態(tài)遷移的語義。以超媒體作為引擎，驅(qū)動(dòng)Web應(yīng)用的狀態(tài)遷移。通過超媒體暴露出服務(wù)器所提供的資源，服務(wù)器提供了哪些資源是在運(yùn)行時(shí)通過解析超媒體發(fā)現(xiàn)的，而不是事先定義的。從面向服務(wù)的角度看，超媒體定義了服務(wù)器所提供服務(wù)的協(xié)議?？蛻舳藨?yīng)該依賴的是超媒體的狀態(tài)遷移語義，而不應(yīng)該對(duì)于是否存在某個(gè)URI或URI的某種特殊構(gòu)造方式作出假

26、設(shè)。一切都有可能變化，只有超媒體的狀態(tài)遷移語義能夠長期保持穩(wěn)定。一旦讀者理解了上述REST的五個(gè)關(guān)鍵詞，就很容易理解REST風(fēng)格的架構(gòu)所具有的6個(gè)的主要特征：· 面向資源（Resource Oriented）· 可尋址（Addressability）· 連通性（Connectedness）· 無狀態(tài)（Statelessness）· 統(tǒng)一接口（Uniform Interface）· 超文本驅(qū)動(dòng)（Hypertext Driven）這6個(gè)特征是REST架構(gòu)設(shè)計(jì)優(yōu)秀程度的判斷標(biāo)準(zhǔn)。其中，面向資源是REST最明顯的特征，即，REST架構(gòu)設(shè)計(jì)是以

27、資源抽象為核心展開的。可尋址說的是：每一個(gè)資源在Web之上都有自己的地址。連通性說的是：應(yīng)該盡量避免設(shè)計(jì)孤立的資源，除了設(shè)計(jì)資源本身，還需要設(shè)計(jì)資源之間的關(guān)聯(lián)關(guān)系，并且通過超鏈接將資源關(guān)聯(lián)起來。無狀態(tài)、統(tǒng)一接口是REST的兩種架構(gòu)約束，超文本驅(qū)動(dòng)是REST的一個(gè)關(guān)鍵詞，在前面都已經(jīng)解釋過，就不再贅述了。從架構(gòu)風(fēng)格的抽象高度來看，常見的分布式應(yīng)用架構(gòu)風(fēng)格有三種：· 分布式對(duì)象（Distributed Objects，簡稱DO）架構(gòu)實(shí)例有CORBA/RMI/EJB/DCOM/.NET Remoting等等· 遠(yuǎn)程過程調(diào)用（Remote Procedure Call，簡稱RPC）

28、架構(gòu)實(shí)例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等· 表述性狀態(tài)轉(zhuǎn)移（Representational State 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支持抽象的工具是對(duì)象。在不同的編程語言中，對(duì)象的定義有很大差別，所以DO風(fēng)格的架構(gòu)通常都是與某種編程語言綁定的?？缯Z言交互即使能實(shí)現(xiàn)，實(shí)現(xiàn)起來也會(huì)非常復(fù)雜。而REST中的資源，則完全中立

29、于開發(fā)平臺(tái)和編程語言，可以使用任何編程語言來實(shí)現(xiàn)。· DO中沒有統(tǒng)一接口的概念。不同的API，接口設(shè)計(jì)風(fēng)格可以完全不同。DO也不支持操作語義對(duì)于中間組件的可見性。· DO中沒有使用超文本，響應(yīng)的內(nèi)容中只包含對(duì)象本身。REST使用了超文本，可以實(shí)現(xiàn)更大粒度的交互，交互的效率比DO更高。· REST支持?jǐn)?shù)據(jù)流和管道，DO不支持?jǐn)?shù)據(jù)流和管道。· DO風(fēng)格通常會(huì)帶來客戶端與服務(wù)器端的緊耦合。在三種架構(gòu)風(fēng)格之中，DO風(fēng)格的耦合度是最大的，而REST的風(fēng)格耦合度是最小的。REST松耦合的源泉來自于統(tǒng)一接口+超文本驅(qū)動(dòng)。REST與RPC的差別在于：· RES

30、T支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風(fēng)格的架構(gòu)建模是以名詞為核心的，RPC風(fēng)格的架構(gòu)建模是以動(dòng)詞為核心的。簡單類比一下，REST是面向?qū)ο缶幊?，RPC則是面向過程編程。· RPC中沒有統(tǒng)一接口的概念。不同的API，接口設(shè)計(jì)風(fēng)格可以完全不同。RPC也不支持操作語義對(duì)于中間組件的可見性。· RPC中沒有使用超文本，響應(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ì)帶來客戶端與服務(wù)器端的緊耦合。支持統(tǒng)一接口+超文本驅(qū)動(dòng)的REST風(fēng)格，可以達(dá)到最小的耦合度。比較了三種架構(gòu)風(fēng)格之間的差別之后，從面向?qū)嵱玫慕嵌葋砜?，REST架構(gòu)風(fēng)格可以為Web開發(fā)者帶來三方面的利