引子

在移動互聯(lián)網、云計算迅猛發(fā)展的今天，作為一名Web 開發(fā)者，如果您還沒聽說過“REST”這個buzzword，顯然已經落伍了。夸張點說，甚至“出了門都不好意思跟別人打招呼”。盡管如此，對于REST 這個泊來品的理解，大多數(shù)人（包括一些資深的架構師）仍然停留在“盲人摸象”的階段。常常聽到各種各樣關于REST 的說法，例如：有人說：“我們這套新的API 決定不用Web Service（SOAP+WSDL），而是直接使用HTTP+JSON，也就是用RESTful 的方式來開發(fā)。” 不用SOAP，甚至也不用XML，就自動變成了RESTful 了。還有人認為：REST 與傳統(tǒng)的Web Service 其實沒有本質區(qū)別，只是對于URI 的構造方式提出了更多要求，而這些要求Web Service 完全都可以實現(xiàn)。潛臺詞是：既生瑜，何生亮。Web Service 已經足夠好了，干嘛還要再折騰什么REST。這些對于REST 的不同說法，果真如此嗎？REST 究竟是什么？是一種新的技術、一種新的架構、還是一種新的規(guī)范？

對于這些問題筆者先不解答，為了深入理解REST 是什么，我們需要回顧一下Web 發(fā)展的最初年代，從源頭上講講REST 是怎么得來的。

Web 技術發(fā)展與 REST 的由來

Web（萬維網 World Wide Web 的簡稱）是個包羅萬象的萬花筒，不同的人從不同的角度觀察，對于 Web 究竟是什么會得出大不相同的觀點。作為 Web 開發(fā)者，我們需要從技術上來理解 Web。從技術架構層面上看，Web 的技術架構包括了四個基石：

• URI
• HTTP
• HyperText（除了 HTML 外，也可以是帶有超鏈接的 XML 或 JSON）
• MIME

這四個基石相互支撐，促使 Web 這座宏偉的大廈以幾何級數(shù)的速度發(fā)展了起來。在這四個基石之上，Web 開發(fā)技術的發(fā)展可以粗略劃分成以下幾個階段：

• 靜態(tài)內容階段：在這個最初的階段，使用 Web 的主要是一些研究機構。Web 由大量的靜態(tài) HTML 文檔組成，其中大多是一些學術論文。Web 服務器可以被看作是支持超文本的共享文件服務器。
• CGI 程序階段：在這個階段，Web 服務器增加了一些編程 API。通過這些 API 編寫的應用程序，可以向客戶端提供一些動態(tài)變化的內容。Web 服務器與應用程序之間的通信，通過 CGI（Common Gateway Interface）協(xié)議完成，應用程序被稱作 CGI 程序。
• 腳本語言階段：在這個階段，服務器端出現(xiàn)了 ASP、PHP、JSP、ColdFusion 等支持 session 的腳本語言技術，瀏覽器端出現(xiàn)了 Java Applet、JavaScript 等技術。使用這些技術，可以提供更加豐富的動態(tài)內容。
• 瘦客戶端應用階段：在這個階段，在服務器端出現(xiàn)了獨立于 Web 服務器的應用服務器。同時出現(xiàn)了 Web MVC 開發(fā)模式，各種 Web MVC 開發(fā)框架逐漸流行，并且占據(jù)了統(tǒng)治地位。基于這些框架開發(fā)的 Web 應用，通常都是瘦客戶端應用，因為它們是在服務器端生成全部的動態(tài)內容。
• RIA 應用階段：在這個階段，出現(xiàn)了多種 RIA（Rich Internet Application）技術，大幅改善了 Web 應用的用戶體驗。應用最為廣泛的 RIA 技術是 DHTML+Ajax。Ajax 技術支持在不刷新頁面的情況下動態(tài)更新頁面中的局部內容。同時誕生了大量的 Web 前端 DHTML 開發(fā)庫，例如 Prototype、Dojo、ExtJS、jQuery/jQuery UI 等等，很多開發(fā)庫都支持單頁面應用（Single Page Application）的開發(fā)。其他的 RIA 技術還有 Adobe 公司的 Flex、微軟公司的 Silverlight、Sun 公司的 JavaFX（現(xiàn)在為 Oracle 公司所有）等等。
• 移動 Web 應用階段：在這個階段，出現(xiàn)了大量面向移動設備的 Web 應用開發(fā)技術。除了 Android、iOS、Windows Phone 等操作系統(tǒng)平臺原生的開發(fā)技術之外，基于 HTML5 的開發(fā)技術也變得非常流行。

從上述 Web 開發(fā)技術的發(fā)展過程看，Web 從最初其設計者所構思的主要支持靜態(tài)文檔的階段，逐漸變得越來越動態(tài)化。Web 應用的交互模式，變得越來越復雜：從靜態(tài)文檔發(fā)展到以內容為主的門戶網站、電子商務網站、搜索引擎、社交網站，再到以娛樂為主的大型多人在線游戲、手機游戲。

在互聯(lián)網行業(yè)，實踐總是走在理論的前面。Web 發(fā)展到了 1995 年，在 CGI、ASP 等技術出現(xiàn)之后，沿用了多年、主要面向靜態(tài)文檔的 HTTP/1.0 協(xié)議已經無法滿足 Web 應用的開發(fā)需求，因此需要設計新版本的 HTTP 協(xié)議。在 HTTP/1.0 協(xié)議專家組之中，有一位年輕人脫穎而出，顯示出了不凡的洞察力，后來他成為了 HTTP/1.1 協(xié)議專家組的負責人。這位年輕人就是 Apache HTTP 服務器的核心開發(fā)者 Roy Fielding，他還是 Apache 軟件基金會的合作創(chuàng)始人。

Roy Fielding 和他的同事們在 HTTP/1.1 協(xié)議的設計工作中，對于 Web 之所以取得巨大成功，在技術架構方面的因素做了一番深入的總結。Fielding 將這些總結納入到了一套理論框架之中，然后使用這套理論框架中的指導原則，來指導 HTTP/1.1 協(xié)議的設計方向。HTTP/1.1 協(xié)議的第一個草稿是在 1996 年 1 月發(fā)布的，經過了三年多時間的修訂，于 1999 年 6 月成為了 IETF 的正式規(guī)范（包括了 RFC 2616 以及用于對客戶端做身份認證的 RFC 2617）。HTTP/1.1 協(xié)議設計的極為成功，以至于發(fā)布之后整整 10 年時間里，都沒有多少人認為有修訂的必要。用來指導 HTTP/1.1 協(xié)議設計的這套理論框架，最初是以備忘錄的形式在專家組成員之間交流，除了 IETF/W3C 的專家圈子，并沒有在外界廣泛流傳。Fielding 在完成 HTTP/1.1 協(xié)議的設計工作之后，回到了加州大學歐文分校繼續(xù)攻讀自己的博士學位。第二年（2000 年）在他的博士學位論文 Architectural Styles and the Design of Network-based Software Architectures 中，F(xiàn)ielding 更為系統(tǒng)、嚴謹?shù)仃U述了這套理論框架，并且使用這套理論框架推導出了一種新的架構風格，并且為這種架構風格取了一個令人輕松愉快的名字“REST”——Representational State Transfer（表述性狀態(tài)轉移）的縮寫。

在筆者看來，F(xiàn)ielding 這篇博士論文在 Web 發(fā)展史上的價值，不亞于 Web 之父 Tim Berners-Lee 關于超文本的那篇經典論文。然而遺憾的是，這篇博士論文在誕生之后的將近 5 年時間里，一直沒有得到足夠的重視。例如 Web Service 相關規(guī)范 SOAP/WSDL 的設計者們，顯然不大理解 REST 是什么，HTTP/1.1 究竟是一個什么樣的協(xié)議、為何要設計成這個樣子。

這種情況在 2005 年之后有了很大的改善，隨著 Ajax、Ruby on Rails 等新的 Web 開發(fā)技術的興起，在 Web 開發(fā)技術社區(qū)掀起了一場重歸 Web 架構設計本源的運動，REST 架構風格得到了越來越多的關注。在 2007 年 1 月，支持 REST 開發(fā)的 Ruby on Rails 1.2 版正式發(fā)布，并且將支持 REST 開發(fā)作為 Rails 未來發(fā)展中的優(yōu)先內容。Ruby on Rails 的創(chuàng)始人 DHH 做了一個名為“World of Resources”的精彩演講，DHH 在 Web 開發(fā)技術社區(qū)中的強大影響力，使得 REST 一下子處在 Web 開發(fā)技術舞臺的聚光燈之下。

今天，各種流行的 Web 開發(fā)框架，幾乎沒有不支持 REST 開發(fā)的了。大多數(shù) Web 開發(fā)者都是通過閱讀某種 REST 開發(fā)框架的文檔，以及通過一些例子代碼來學習 REST 開發(fā)的。然而，通過例子代碼來學習 REST 有非常大的局限性。因為 REST 并不是一種具體的技術，也不是一種具體的規(guī)范，REST 其實是一種內涵非常豐富的架構風格。通過例子代碼來學習 REST，除了學習到一種有趣的 Web 開發(fā)技術之外，并不能全面深入的理解 REST 究竟是什么。甚至還會誤以為這些簡單的例子代碼就是 REST 本身，REST 不過是一種簡單的 Web 開發(fā)技術而已。就像盲人摸象一樣，有的人摸到了象鼻子、有的人摸到了象耳朵、有的人摸到了象腿、有的人摸到了象尾巴。他們都堅信自己感覺到的大象，才是最真實的大象，而其他人的感覺都是錯誤的。

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

在 Fielding 的這篇名為 Architectural Styles and the Design of Network-based Software Architectures 的博士論文（中文版名為《架構風格與基于網絡的軟件架構設計》）中，提出了一整套基于網絡的軟件（即所謂的“分布式應用”）的設計方法，值得所有分布式應用的開發(fā)者仔細閱讀、深入體會。

在論文的前三章中，F(xiàn)ielding 在批判性繼承前人研究成果的基礎上，建立起來一整套研究和評價軟件架構的方法論。這套方法論的核心是“架構風格”這個概念。架構風格是一種研究和評價軟件架構設計的方法，它是比架構更加抽象的概念。一種架構風格是由一組相互協(xié)作的架構約束來定義的。架構約束是指軟件的運行環(huán)境施加在架構設計之上的約束。

在論文的第四章中，F(xiàn)ielding 研究了 Web 這樣一個分布式系統(tǒng)對于軟件架構設計提出了哪些需求。在第五章中，F(xiàn)ielding 將第四章 Web 提出的需求具體化為一些架構約束，通過逐步添加各種架構約束，推導出來了 REST 這種新的架構風格。

REST 架構風格的推導過程

圖 1：REST 所繼承的架構風格約束

在圖1 中，每一個橢圓形里面的縮寫詞代表了一種架構風格，而每一個箭頭邊的單詞代表了一種架構約束。

REST 架構風格最重要的架構約束有 6 個：

• 客戶 - 服務器（Client-Server）

通信只能由客戶端單方面發(fā)起，表現(xiàn)為請求 - 響應的形式。

• 無狀態(tài)（Stateless）

通信的會話狀態(tài)（Session State）應該全部由客戶端負責維護。

• 緩存（Cache）

響應內容可以在通信鏈的某處被緩存，以改善網絡效率。

• 統(tǒng)一接口（Uniform Interface）

通信鏈的組件之間通過統(tǒng)一的接口相互通信，以提高交互的可見性。

• 分層系統(tǒng)（Layered System）

通過限制組件的行為（即，每個組件只能“看到”與其交互的緊鄰層），將架構分解為若干等級的層。

• 按需代碼（Code-On-Demand，可選）

支持通過下載并執(zhí)行一些代碼（例如 Java Applet、Flash 或 JavaScript），對客戶端的功能進行擴展。

在論文中推導出的 REST 架構風格如下圖所示：

圖 2：REST 架構風格

而HTTP/1.1 協(xié)議作為一種REST 架構風格的架構實例，其架構如下圖所示：

圖3：一個基于REST 的架構的過程視圖

用戶代理處在三個并行交互（a、b 和c）的中間。用戶代理的客戶端連接器緩存無法滿足請求，因此它根據(jù)每個資源標識符的屬性和客戶端連接器的配置，將每個請求路由到資源的來源。請求（a）被發(fā)送到一個本地代理，代理隨后訪問一個通過DNS 查找發(fā)現(xiàn)的緩存網關，該網關將這個請求轉發(fā)到一個能夠滿足該請求的來源服務器，服務器的內部資源由一個封裝過的對象請求代理（object request broker）架構來定義。請求（b）直接發(fā)送到一個來源服務器，它能夠通過自己的緩存來滿足這個請求。請求（c）被發(fā)送到一個代理，它能夠直接訪問WAIS（一種與Web 架構分離的信息服務），并將WAIS 的響應翻譯為一種通用的連接器接口能夠識別的格式。每一個組件只知道與它們自己的客戶端或服務器連接器的交互；整個過程拓撲是我們的視圖的產物。

通過比較圖2 和圖3，讀者不難發(fā)現(xiàn)這兩張圖中的架構是高度一致的。對于HTTP/1.1 協(xié)議為何要設計成這個樣子，讀者想必已經有所領悟。

在論文的第六章中，F(xiàn)ielding 對于到2000 年為止在Web 基礎架構協(xié)議的設計和開發(fā)方面的一些經驗教訓進行了深入的分析。其中，“HTTP 不是RPC”、“HTTP 不是一種傳輸協(xié)議”兩部分值得讀者反復閱讀。時至13 年之后的今日，對于HTTP 協(xié)議的誤解仍然廣泛存在。

以上簡要介紹了Fielding 博士論文中的內容。為了幫助讀者仔細閱讀Fielding 的博士論文，筆者整理了一套Fielding 博士論文的導讀。

REST 詳解

REST 究竟是什么？因為 REST 的內涵非常豐富，所以很難用一兩句話解釋清楚這個問題。

首先，REST 是 Web 自身的架構風格。REST 也是 Web 之所以取得成功的技術架構方面因素的總結。REST 是世界上最成功的分布式應用架構風格（成功案例：Web，還不夠嗎？）。它是為 運行在互聯(lián)網環(huán)境 的 分布式 超媒體系統(tǒng)量身定制的?；ヂ?lián)網環(huán)境與企業(yè)內網環(huán)境有非常大的差別，最主要的差別是兩個方面：

• 可伸縮性需求無法控制：并發(fā)訪問量可能會暴漲，也可能會暴跌。
• 安全性需求無法控制：無法控制客戶端發(fā)來的請求的格式，很可能會是惡意的請求。

而所謂的“超媒體系統(tǒng)”，即，使用了超文本的系統(tǒng)?？梢园?ldquo;超媒體”理解為超文本 + 媒體內容。

REST 是 HTTP/1.1 協(xié)議等 Web 規(guī)范的設計指導原則，HTTP/1.1 協(xié)議正是為實現(xiàn) REST 風格的架構而設計的。新的 Web 規(guī)范，其設計必須符合 REST 的要求，否則整個 Web 的體系架構會因為引入嚴重矛盾而崩潰。這句話不是危言聳聽，做個類比，假如蘇州市政府同意在市區(qū)著名園林的附近大型土木，建造大量具有后現(xiàn)代風格的摩天大樓，那么不久之后世界聞名的蘇州園林美景將不復存在。

上述這些關于“REST 是什么”的描述，可以總結為一句話：REST 是所有 Web 應用都應該遵守的架構設計指導原則。當然，REST 并不是法律，違反了 REST 的指導原則，仍然能夠實現(xiàn)應用的功能。但是違反了 REST 的指導原則，會付出很多代價，特別是對于大流量的網站而言。

要深入理解 REST，需要理解 REST 的五個關鍵詞：

• 資源（Resource）
• 資源的表述（Representation）
• 狀態(tài)轉移（State Transfer）
• 統(tǒng)一接口（Uniform Interface）
• 超文本驅動（Hypertext Driven）

什么是資源？

資源是一種看待服務器的方式，即，將服務器看作是由很多離散的資源組成。每個資源是服務器上一個可命名的抽象概念。因為資源是一個抽象的概念，所以它不僅僅能代表服務器文件系統(tǒng)中的一個文件、數(shù)據(jù)庫中的一張表等等具體的東西，可以將資源設計的要多抽象有多抽象，只要想象力允許而且客戶端應用開發(fā)者能夠理解。與面向對象設計類似，資源是以名詞為核心來組織的，首先關注的是名詞。一個資源可以由一個或多個 URI 來標識。URI 既是資源的名稱，也是資源在 Web 上的地址。對某個資源感興趣的客戶端應用，可以通過資源的 URI 與其進行交互。

什么是資源的表述？

資源的表述是一段對于資源在某個特定時刻的狀態(tài)的描述?？梢栽诳蛻舳?- 服務器端之間轉移（交換）。資源的表述可以有多種格式，例如 HTML/XML/JSON/ 純文本 / 圖片 / 視頻 / 音頻等等。資源的表述格式可以通過協(xié)商機制來確定。請求 - 響應方向的表述通常使用不同的格式。

什么是狀態(tài)轉移？

狀態(tài)轉移（state transfer）與狀態(tài)機中的狀態(tài)遷移（state transition）的含義是不同的。狀態(tài)轉移說的是：在客戶端和服務器端之間轉移（transfer）代表資源狀態(tài)的表述。通過轉移和操作資源的表述，來間接實現(xiàn)操作資源的目的。

什么是統(tǒng)一接口？

REST 要求，必須通過統(tǒng)一的接口來對資源執(zhí)行各種操作。對于每個資源只能執(zhí)行一組有限的操作。以 HTTP/1.1 協(xié)議為例，HTTP/1.1 協(xié)議定義了一個操作資源的統(tǒng)一接口，主要包括以下內容：

• 7 個 HTTP 方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
• HTTP 頭信息（可自定義）
• HTTP 響應狀態(tài)代碼（可自定義）
• 一套標準的內容協(xié)商機制
• 一套標準的緩存機制
• 一套標準的客戶端身份認證機制

REST 還要求，對于資源執(zhí)行的操作，其操作語義必須由 HTTP 消息體之前的部分完全表達，不能將操作語義封裝在 HTTP 消息體內部。這樣做是為了提高交互的可見性，以便于通信鏈的中間組件實現(xiàn)緩存、安全審計等等功能。

什么是超文本驅動？

“超文本驅動”又名“將超媒體作為應用狀態(tài)的引擎”（Hypermedia As The Engine Of Application State，來自 Fielding 博士論文中的一句話，縮寫為 HATEOAS）。將 Web 應用看作是一個由很多狀態(tài)（應用狀態(tài)）組成的有限狀態(tài)機。資源之間通過超鏈接相互關聯(lián)，超鏈接既代表資源之間的關系，也代表可執(zhí)行的狀態(tài)遷移。在超媒體之中不僅僅包含數(shù)據(jù)，還包含了狀態(tài)遷移的語義。以超媒體作為引擎，驅動 Web 應用的狀態(tài)遷移。通過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時通過解析超媒體發(fā)現(xiàn)的，而不是事先定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協(xié)議?？蛻舳藨撘蕾嚨氖浅襟w的狀態(tài)遷移語義，而不應該對于是否存在某個 URI 或 URI 的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態(tài)遷移語義能夠長期保持穩(wěn)定。

一旦讀者理解了上述 REST 的五個關鍵詞，就很容易理解 REST 風格的架構所具有的 6 個的主要特征：

• 面向資源（Resource Oriented）
• 可尋址（Addressability）
• 連通性（Connectedness）
• 無狀態(tài)（Statelessness）
• 統(tǒng)一接口（Uniform Interface）
• 超文本驅動（Hypertext Driven）

這 6 個特征是 REST 架構設計優(yōu)秀程度的判斷標準。其中，面向資源是 REST 最明顯的特征，即，REST 架構設計是以資源抽象為核心展開的?？蓪ぶ氛f的是：每一個資源在 Web 之上都有自己的地址。連通性說的是：應該盡量避免設計孤立的資源，除了設計資源本身，還需要設計資源之間的關聯(lián)關系，并且通過超鏈接將資源關聯(lián)起來。無狀態(tài)、統(tǒng)一接口是 REST 的兩種架構約束，超文本驅動是 REST 的一個關鍵詞，在前面都已經解釋過，就不再贅述了。

從架構風格的抽象高度來看，常見的分布式應用架構風格有三種：

• 分布式對象（Distributed Objects，簡稱 DO）

架構實例有 CORBA/RMI/EJB/DCOM/.NET Remoting 等等

• 遠程過程調用（Remote Procedure Call，簡稱 RPC）

架構實例有 SOAP/XML-RPC/Hessian/Flash AMF/DWR 等等

• 表述性狀態(tài)轉移（Representational State Transfer，簡稱 REST）

架構實例有 HTTP/WebDAV

DO 和 RPC 這兩種架構風格在企業(yè)應用中非常普遍，而 REST 則是 Web 應用的架構風格，它們之間有非常大的差別。

REST 與 DO 的差別

• REST 支持抽象（即建模）的工具是資源，DO 支持抽象的工具是對象。在不同的編程語言中，對象的定義有很大差別，所以 DO 風格的架構通常都是與某種編程語言綁定的。跨語言交互即使能實現(xiàn)，實現(xiàn)起來也會非常復雜。而 REST 中的資源，則完全中立于開發(fā)平臺和編程語言，可以使用任何編程語言來實現(xiàn)。
• DO 中沒有統(tǒng)一接口的概念。不同的 API，接口設計風格可以完全不同。DO 也不支持操作語義對于中間組件的可見性。
• DO 中沒有使用超文本，響應的內容中只包含對象本身。REST 使用了超文本，可以實現(xiàn)更大粒度的交互，交互的效率比 DO 更高。
• REST 支持數(shù)據(jù)流和管道，DO 不支持數(shù)據(jù)流和管道。
• DO 風格通常會帶來客戶端與服務器端的緊耦合。在三種架構風格之中，DO 風格的耦合度是最大的，而 REST 的風格耦合度是最小的。REST 松耦合的源泉來自于統(tǒng)一接口 + 超文本驅動。

REST 與 RPC 的差別

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

比較了三種架構風格之間的差別之后，從面向實用的角度來看，REST 架構風格可以為 Web 開發(fā)者帶來三方面的利益：

• 簡單性

采用 REST 架構風格，對于開發(fā)、測試、運維人員來說，都會更簡單?？梢猿浞掷么罅?HTTP 服務器端和客戶端開發(fā)庫、Web 功能測試 / 性能測試工具、HTTP 緩存、HTTP 代理服務器、防火墻。這些開發(fā)庫和基礎設施早已成為了日常用品，不需要什么火箭科技（例如神奇昂貴的應用服務器、中間件）就能解決大多數(shù)可伸縮性方面的問題。

• 可伸縮性

充分利用好通信鏈各個位置的 HTTP 緩存組件，可以帶來更好的可伸縮性。其實很多時候，在 Web 前端做性能優(yōu)化，產生的效果不亞于僅僅在服務器端做性能優(yōu)化，但是 HTTP 協(xié)議層面的緩存常常被一些資深的架構師完全忽略掉。

• 松耦合

統(tǒng)一接口 + 超文本驅動，帶來了最大限度的松耦合。允許服務器端和客戶端程序在很大范圍內，相對獨立地進化。對于設計面向企業(yè)內網的 API 來說，松耦合并不是一個很重要的設計關注點。但是對于設計面向互聯(lián)網的 API 來說，松耦合變成了一個必選項，不僅在設計時應該關注，而且應該放在最優(yōu)先位置。

有的讀者可能會問：“你說了這么多，REST 難道就沒有任何缺點了嗎？”當然不是，正如 Fielding 在博士論文中闡述的那樣，評價一種軟件架構的優(yōu)劣，不能脫離開軟件的具體運行環(huán)境。永遠不存在適用于任何運行環(huán)境的、包治百病的銀彈式架構。筆者在前面強調過 REST 是一種為運行在互聯(lián)網環(huán)境中的 Web 應用量身定制的架構風格。REST 在互聯(lián)網這個運行環(huán)境之中已經占據(jù)了統(tǒng)治地位，然而，在企業(yè)內網運行環(huán)境之中，REST 還會面臨 DO、RPC 的巨大挑戰(zhàn)。特別是一些對實時性要求很高的應用，REST 的表現(xiàn)不如 DO 和 RPC。所以需要針對具體的運行環(huán)境來具體問題具體分析。但是，REST 可以帶來的上述三方面的利益即使在開發(fā)企業(yè)應用時，仍然是非常有價值的。所以 REST 在企業(yè)應用開發(fā)，特別是在 SOA 架構的開發(fā)中，已經得到了越來越大的重視。本專欄將有一篇文章專門介紹 REST 在企業(yè)級應用中與 SOA 的結合。

到了這里，“REST 究竟是什么”這個問題筆者就解答完了。本文開頭那些說法是否正確，筆者還是笑而不語，讀者此時應該已經有了自己的判斷。在接下來的 REST 系列文章中，我將會為讀者澄清一些關于 HTTP 協(xié)議和 REST 的常見誤解。

參考資料：

Roy Fielding 博士論文英文版

Roy Fielding 博士論文中文版

以上就是本真的REST架構風格理解的詳細內容，更多關于REST架構風格的資料請關注腳本之家其它相關文章！

最新評論