これは本当にRESTアーキテクチャスタイルを理解します

この記事では、列「RESTの詳細な探査」のコンテンツの深さの二seriesで、それは、あなたのWeb、RESTアーキテクチャの性質と特性との比較だけでなく、他の建築様式RESTアーキテクチャとの関係をRESTアーキテクチャの起源の味を取ります。

プライマー

あなたは「REST」のキャッチフレーズで聞いたことがない場合は、モバイルインターネットでは、クラウドコンピューティングの急速な発展、今日は、Web開発者として、明らかに時代遅れになってきました。でも、と言っても過言で「ドアアウトは、他の人と挨拶して恥ずかしいです。」ただし、商品に駐車し、この理解RESTのために、（一部のシニアアーキテクトを含む）ほとんどの人はまだ「象」の段階にとどまります。多くの場合、RESTの多種多様に言って聞いて、例えば：「我々は開発するRESTfulな方法です。この新しいAPI Webサービス（SOAP + WSDL）が、HTTP + JSONの直接の使用を、使用しないことを決定：一部の人々は言います。「SOAPせずに、でもXMLせず、それが自動的にRESTfulになります。一部の人々は信じている：伝統的な事実とREST Webサービスをそこには本質的な違いはありませんが、より多くの要求をURIを構築する方法は、これらの要件は完全にWebサービスを実現することができます。言外の意味は次のとおりです。両方シェンゆう、盛亮。Webサービスは、なぜ何RESTを投げる必要があり、十分に良いされています。RESTのこれらの異なるバージョンについては、本当に？RESTは正確には何ですか？新しい技術、新しいアーキテクチャや新たな規範がありますか？

私は答えていないこれらの質問の最初のために、我々はWeb開発の早期年間を振り返っする必要がありますされているものRESTの深い理解のために、RESTの話では、ソースから来るかです。

Web技術の開発とRESTの起源

ウェブ（略してWWWのWorld Wide Web）は、ビューの非常に異なる地点に来るものをWeb用に、すべての包括的な万華鏡、異なる角度から見た別の人です。Web開発者として、私たちはWeb技術から理解して来る必要があります。技術的な観点からアーキテクチャレベル、Web技術のアーキテクチャでは、4個の礎石で構成されています。

• URI
• HTTP
• ハイパーテキスト（HTMLに加えて、だけでなく、XMLやJSONハイパーリンクすることができます）
• MIME

相互支援の4個の礎石は、この壮大な建物のWeb幾何学的にペースアップを促進します。Web開発技術の開発の4個の礎石の上に大まかに次のフェーズに分けることができます：

1. 静的コンテンツの段階：この初期段階では、主にいくつかの研究機関をWebを使用します。そのほとんど静的なHTML文書、多数のことでWebが論文の一部です。Webサーバは、ハイパーテキストのための共有ファイルサーバのサポートとして見ることができます。
2. CGIプログラムのステージは：この段階では、Webサーバーは、いくつかのプログラミングAPIが追加されます。API書かれたこれらのアプリケーションは、それがクライアントにいくつかの動的なコンテンツを提供することができます。Webサーバ及びCGI（Common Gateway Interface）プロトコルを介してアプリケーション間の通信は、アプリケーションがCGIプログラムと呼ばれ、完成されています。
3. スクリプト言語の段階：この段階では、サーバはASP、PHP、JSP、ColdFusionスクリプト言語技術サポートセッションが登場、ブラウザには、Javaアプレット、JavaScriptや他の技術が登場。これらの技術を使用して、我々はより豊かな動的コンテンツを提供することができます。
4. シン・クライアント・アプリケーションのステージは：この段階では、アプリケーションサーバのサーバ側は、Webサーバーから独立して表示されます。ウェブMVC開発モデルがあったと同時に、様々なウェブMVC開発のフレームワークが人気を集め、そして支配的な地位を占めています。彼らはすべてサーバ側で動的なコンテンツを生成しているため、これらの開発のためのWebベースのアプリケーションフレームワークは、通常、シンクライアントアプリケーションです。
5. RIAアプリケーションの段階：この段階では、大幅にWebアプリケーションのユーザーエクスペリエンスを向上させるRIA（リッチインターネットアプリケーション）技術の様々な。最も広く使用されているRIA技術はDHTML + Ajaxのです。ページを更新せずにローカルコンテンツのAjaxの技術サポート動的更新ページ。同時に、このようなプロトタイプ、道場、ExtJSに、jQueryの/ jQueryのUIやなどのWebフロントエンドDHTML開発ライブラリ、多数の誕生がそうで、開発ライブラリの多くは、単一ページのアプリケーション（単一ページのアプリケーション）の開発をサポートしています。その上、他のRIA技術だけでなく、AdobeのFlexのは、MicrosoftのSilverlight、SunのJavaFXの（現在オラクル社すべて）、および。
6. モバイルWebアプリケーションの段階：この段階では、モバイルデバイス用のWebアプリケーション開発技術が多数ありました。アンドロイド、iOSの、Windowsの携帯電話やその他のオペレーティング・システム・プラットフォームのネイティブの技術開発に加えて、HTML5ベースの開発技術は、非常に人気となっています。

上記のWeb開発技術の視点の開発プロセスからは、メインの舞台から徐々に、ますますダイナミックになってきて、その設計者は元々考え静的なWebドキュメントをサポートしています。対話モードのWebアプリケーションは、より複雑になる：エンターテインメントベースの多人数同時参加型オンラインゲームに、静的コンテンツベースのポータル、Eコマースサイト、検索エンジン、ソーシャルネットワーキングサイトから開発を文書化するために、モバイルゲーム。

インターネット業界では、実際には、常に先理論のです。1995年にウェブ開発は、CGIの後、ASPおよびその他の技術は、主に静的なドキュメントのために、長年にわたって使用して、表示されたHTTP / 1.0プロトコルは、HTTPプロトコルの新しいバージョンを設計する必要がある、Webアプリケーションの開発ニーズを満たすことができませんでした。HTTP / 1.0プロトコルの専門家グループの中で、若い男が異常な洞察力を示す、前面に来て、そして後、彼はHTTP / 1.1プロトコルの専門家グループの頭になりました。若い男は、Apache HTTP Serverのロイ・フィールディングのコア開発者である、彼は、Apache Software Foundationの共同創設者でした。

ロイ・フィールディングとテクニカル要因アーキテクチャの面で大きな成功のためのHTTP / 1.1プロトコル、ウェブ理由の設計における彼の同僚は、いくつかの綿密な要約をしました。守備は、理論的な枠組みの中で、これらの要約に組み込まれ、HTTP / 1.1プロトコルの設計方向を案内するために、この理論的な枠組みのガイドラインを使用します。HTTP / 1.1プロトコルの最初のドラフトは1996年1月にリリースされた、それは三年以上改定し、1999年6月にIETF（RFC 2616の正式な仕様となり、クライアントが何をするために含まれています認証RFC 2617）。完全な10年のリリース後、多くの人々が必要な改正を検討していないように、非常に成功のために設計されたHTTP / 1.1プロトコル。この理論的な専門家のサークルIETF / W3Cに加えて、最初はグループのメンバー間の交流の覚書の形で、HTTP / 1.1プロトコルの設計を導くために使用されるフレームワーク、そして外の世界で普及していません。HTTP / 1.1プロトコルの設計作業が完了した後守備、彼は彼の博士号を追求するためにカリフォルニア大学アーバイン校に戻りました。彼の博士論文の建築様式で、来年（2000年）と、この理論的な枠組みのより体系的かつ厳格な博覧会フィールディングでは、ネットワークベースのソフトウェアアーキテクチャの設計、およびこの理論の枠組みを使用して導出されます新しい建築スタイルの種類、および、そのような建築スタイルのために非常に気軽名「REST」を取った - の略語のRepresentational State転送（Representational State Transfer）を。

古典的な紙のハイパーテキストについて読んウェブ父ティム・バーナーズ=リーなものとして、多くのウェブの歴史の中で、この博士論文の私の意見では、フィールディング値、。しかし、残念ながら、年間の出生後5年近くでこの博士論文は、十分な注意されていません。このようSOAP / WSDLの設計者として、Webサービス関連の仕様は明らかにRESTが何であるかを理解していない、HTTP / 1.1なぜこのように設計する必要があります契約のまさに一種、です。

この場合、2005年以降大幅にRailsとWebアーキテクチャの運動の原点復帰をオフに設定し、コミュニティ内の他のWeb開発技術上のRubyはRESTアーキテクチャ、新しいWeb開発技術のAjaxの上昇に伴って、改善されましたスタイルはますます注目されています。2007年1月には、RESTは正式にリリースRailsのバージョン1.2上でのRubyの開発を支援し、コンテンツの将来の発展の重点としてREST Railsの開発をサポートします。DHHと呼ばれるグループのRailsの創設者のRubyは、「資源の世界」素晴らしいスピーチ、RESTのWeb開発技術分野一度スポットライトの下にあるWeb技術コミュニティの発展にDHH強い影響力を行います。

今日は、人気の高いWeb開発フレームワークの様々な、少しRESTの開発をサポートしていません。ほとんどのWeb開発者は、RESTの開発を学習するだけでなく、いくつかのサンプルコードをいくつかのドキュメントのREST開発フレームワークを読み込むことです。しかし、サンプルコードによる学習は、非常に大きな制限を置きます。RESTは、特定の技術ではない、またそれが特定の仕様であるため、RESTは実際に建築様式の非常に豊かな意味合いです。RESTは、Web開発技術に楽しい追加を学習に加えて、サンプルコードで学ぶ、およびRESTが本当に何であるかを包括的に深い理解することはできません。さえ間違わこれらの簡単なサンプルコード自体はRESTであるか、RESTは単純なWeb開発技術です。象のように、象の鼻は何人かの人々に触れ、一部の人々は象の耳に触れ、一部の人は、足を触れたいと尻尾のような一部の人に触れました。彼らは他の人が間違っていると感じながら、最も本物の象である、彼は象を感じる確信しています。

Web開発者は、RESTを理解していないために、彼らはRESTを理解させるためのコードのいくつかの例を示すために使用の人々が、私はこの練習を同意しません。Web開発者がどのようなRESTの深い理解を望んでいるならば、このフィールディングの博士論文を回避することは困難であるということです。この記事では何のRESTのために、著者はフィールディングの博士論文に基づいても、導入されます。それにもかかわらず、私は強くちょうど最初の他の人が同じことを中継読むの​​ではなく、孔子の思想は、 『論語』や他の作品を読むことを向けるべき学びたい、フィールディングの博士論文に取り掛かると読むために、この記事の読者をお勧めします。この記事では、著者は、唯一のツイストによって誤って発音の本をやろうとしているし、それを誤って伝えています。それでは、仕事に取り掛かるてみましょう。

フィールディングの本と呼ばれる建築様式と（「ネットワークベースのソフトウェアアーキテクチャの建築様式とデザイン」と呼ばれる中国語版）の博士論文のネットワークベースのソフトウェアアーキテクチャの設計は、Webベースのソフトウェアのセットを提案している（IEでいわゆる「分散アプリケーション」）の設計方法、豊富な経験、すべての分散アプリケーションの開発者が読むことの価値があります。

論文の最初の3つの章では、研究と評価ソフトウェアアーキテクチャの方法論を確立セットの以前の研究の重要な相続結果に基づいて、フィールディング。この方法論の核心は、「建築スタイル」のコンセプトです。建築様式は、アーキテクチャの概念よりも抽象的で、研究と評価ソフトウェアアーキテクチャ設計の方法です。建築様式を定義するために協力の建築制約のセットです。アーキテクチャ制約はオペレーティング環境ソフトウェアのアーキテクチャ上の制約を課すされます。

第四章では、フィールディングは、需要をしたような分散システムのソフトウェアアーキテクチャ設計のためのWebを学びました。第五章では、フィールディングは、徐々に、アーキテクチャ制約の様々なを追加することによって、我々は新しいRESTアーキテクチャ・スタイルを派生し、建築制約のいくつかを具現化第四章のWebによって引き上げ要求します。

RESTアーキテクチャ・スタイルの導出過程は以下の通り：

図1：RESTアーキテクチャスタイル継承された制約（アートワークはここからダウンロードすることができます）

在图 1 中，每一个椭圆形里面的缩写词代表了一种架构风格，而每一个箭头边的单词代表了一种架构约束。

REST 架构风格最重要的架构约束有 6 个：

• 客户 - 服务器（Client-Server）

通信只能由客户端单方面发起，表现为请求 - 响应的形式。

• 无状态（Stateless）

通信的会话状态（Session State）应该全部由客户端负责维护。

• 缓存（Cache）

响应内容可以在通信链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）

通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

• 分层系统（Layered System）

通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

• 按需代码（Code-On-Demand，可选）

支持通过下载并执行一些代码（例如 Java Applet、Flash 或 JavaScript），对客户端的功能进行扩展。

在论文中推导出的 REST 架构风格如下图所示：

图 2：REST 架构风格（原图可在这里下载）

 

而 HTTP/1.1 协议作为一种 REST 架构风格的架构实例，其架构如下图所示：

图 3：一个基于 REST 的架构的过程视图（原图可在这里下载）

用户代理处在三个并行交互（a、b 和 c）的中间。用户代理的客户端连接器缓存无法满足请求，因此它根据每个资源标识符的属性和客户端连接器的配置，将每个请求路由到资源的来源。请求（a）被发送到一个本地代理，代理随后访问一个通过 DNS 查找发现的缓存网关，该网关将这个请求转发到一个能够满足该请求的来源服务器，服务器的内部资源由一个封装过的对象请求代理（object request broker）架构来定义。请求（b）直接发送到一个来源服务器，它能够通过自己的缓存来满足这个请求。请求（c）被发送到一个代理，它能够直接访问 WAIS（一种与 Web 架构分离的信息服务），并将 WAIS 的响应翻译为一种通用的连接器接口能够识别的格式。每一个组件只知道与它们自己的客户端或服务器连接器的交互；整个过程拓扑是我们的视图的产物。

通过比较图 2 和图 3，读者不难发现这两张图中的架构是高度一致的。对于 HTTP/1.1 协议为何要设计成这个样子，读者想必已经有所领悟。

在论文的第六章中，Fielding 对于到 2000 年为止在 Web 基础架构协议的设计和开发方面的一些经验教训进行了深入的分析。其中，“HTTP 不是 RPC”、“HTTP 不是一种传输协议”两部分值得读者反复阅读。时至 13 年之后的今日，对于 HTTP 协议的误解仍然广泛存在。

以上简要介绍了 Fielding 博士论文中的内容。为了帮助读者仔细阅读 Fielding 的博士论文，笔者整理了一套 Fielding 博士论文的导读，将在本专栏后续文章中载出。

REST 详解

REST 究竟是什么？因为 REST 的内涵非常丰富，所以很难用一两句话解释清楚这个问题。

首先，REST 是 Web 自身的架构风格。REST 也是 Web 之所以取得成功的技术架构方面因素的总结。REST 是世界上最成功的分布式应用架构风格（成功案例：Web，还不够吗？）。它是为 运行在互联网环境 的 分布式 超媒体系统量身定制的。互联网环境与企业内网环境有非常大的差别，最主要的差别是两个方面：

• 可伸缩性需求无法控制：并发访问量可能会暴涨，也可能会暴跌。

• 安全性需求无法控制：无法控制客户端发来的请求的格式，很可能会是恶意的请求。

而所谓的“超媒体系统”，即，使用了超文本的系统。可以把“超媒体”理解为超文本 + 媒体内容。

REST 是 HTTP/1.1 协议等 Web 规范的设计指导原则，HTTP/1.1 协议正是为实现 REST 风格的架构而设计的。新的 Web 规范，其设计必须符合 REST 的要求，否则整个 Web 的体系架构会因为引入严重矛盾而崩溃。这句话不是危言耸听，做个类比，假如苏州市政府同意在市区著名园林的附近大型土木，建造大量具有后现代风格的摩天大楼，那么不久之后世界闻名的苏州园林美景将不复存在。

上述这些关于“REST 是什么”的描述，可以总结为一句话：REST 是所有 Web 应用都应该遵守的架构设计指导原则。当然，REST 并不是法律，违反了 REST 的指导原则，仍然能够实现应用的功能。但是违反了 REST 的指导原则，会付出很多代价，特别是对于大流量的网站而言。

要深入理解 REST，需要理解 REST 的五个关键词：

1. 资源（Resource）
2. 资源的表述（Representation）
3. 状态转移（State Transfer）
4. 统一接口（Uniform Interface）
5. 超文本驱动（Hypertext Driven）

什么是资源？

资源是一种看待服务器的方式，即，将服务器看作是由很多离散的资源组成。每个资源是服务器上一个可命名的抽象概念。因为资源是一个抽象的概念，所以它不仅仅能代表服务器文件系统中的一个文件、数据库中的一张表等等具体的东西，可以将资源设计的要多抽象有多抽象，只要想象力允许而且客户端应用开发者能够理解。与面向对象设计类似，资源是以名词为核心来组织的，首先关注的是名词。一个资源可以由一个或多个 URI 来标识。URI 既是资源的名称，也是资源在 Web 上的地址。对某个资源感兴趣的客户端应用，可以通过资源的 URI 与其进行交互。

什么是资源的表述？

资源的表述是一段对于资源在某个特定时刻的状态的描述。可以在客户端 - 服务器端之间转移（交换）。资源的表述可以有多种格式，例如 HTML/XML/JSON/ 纯文本 / 图片 / 视频 / 音频等等。资源的表述格式可以通过协商机制来确定。请求 - 响应方向的表述通常使用不同的格式。

什么是状态转移？

状态转移（state transfer）与状态机中的状态迁移（state transition）的含义是不同的。状态转移说的是：在客户端和服务器端之间转移（transfer）代表资源状态的表述。通过转移和操作资源的表述，来间接实现操作资源的目的。

什么是统一接口？

REST 要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以 HTTP/1.1 协议为例，HTTP/1.1 协议定义了一个操作资源的统一接口，主要包括以下内容：

• 7 个 HTTP 方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

• HTTP 头信息（可自定义）

• HTTP 响应状态代码（可自定义）

• 一套标准的内容协商机制

• 一套标准的缓存机制

• 一套标准的客户端身份认证机制

REST 还要求，对于资源执行的操作，其操作语义必须由 HTTP 消息体之前的部分完全表达，不能将操作语义封装在 HTTP 消息体内部。这样做是为了提高交互的可见性，以便于通信链的中间组件实现缓存、安全审计等等功能。

什么是超文本驱动？

“超文本驱动”又名“将超媒体作为应用状态的引擎”（Hypermedia As The Engine Of Application State，来自 Fielding 博士论文中的一句话，缩写为 HATEOAS）。将 Web 应用看作是一个由很多状态（应用状态）组成的有限状态机。资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执行的状态迁移。在超媒体之中不仅仅包含数据，还包含了状态迁移的语义。以超媒体作为引擎，驱动 Web 应用的状态迁移。通过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运行时通过解析超媒体发现的，而不是事先定义的。从面向服务的角度看，超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义，而不应该对于是否存在某个 URI 或 URI 的某种特殊构造方式作出假设。一切都有可能变化，只有超媒体的状态迁移语义能够长期保持稳定。

一旦读者理解了上述 REST 的五个关键词，就很容易理解 REST 风格的架构所具有的 6 个的主要特征：

• 面向资源（Resource Oriented）

• 可寻址（Addressability）

• 连通性（Connectedness）

• 无状态（Statelessness）

• 统一接口（Uniform Interface）

• 超文本驱动（Hypertext Driven）

这 6 个特征是 REST 架构设计优秀程度的判断标准。其中，面向资源是 REST 最明显的特征，即，REST 架构设计是以资源抽象为核心展开的。可寻址说的是：每一个资源在 Web 之上都有自己的地址。连通性说的是：应该尽量避免设计孤立的资源，除了设计资源本身，还需要设计资源之间的关联关系，并且通过超链接将资源关联起来。无状态、统一接口是 REST 的两种架构约束，超文本驱动是 REST 的一个关键词，在前面都已经解释过，就不再赘述了。

从架构风格的抽象高度来看，常见的分布式应用架构风格有三种：

• 分布式对象（Distributed Objects，简称 DO）

架构实例有 CORBA/RMI/EJB/DCOM/.NET Remoting 等等

• 远程过程调用（Remote Procedure Call，简称 RPC）

架构实例有 SOAP/XML-RPC/Hessian/Flash AMF/DWR 等等

• 表述性状态转移（Representational State Transfer，简称 REST）

架构实例有 HTTP/WebDAV

DO 和 RPC 这两种架构风格在企业应用中非常普遍，而 REST 则是 Web 应用的架构风格，它们之间有非常大的差别。

REST 与 DO 的差别在于：

• REST 支持抽象（即建模）的工具是资源，DO 支持抽象的工具是对象。在不同的编程语言中，对象的定义有很大差别，所以 DO 风格的架构通常都是与某种编程语言绑定的。跨语言交互即使能实现，实现起来也会非常复杂。而 REST 中的资源，则完全中立于开发平台和编程语言，可以使用任何编程语言来实现。

• DO 中没有统一接口的概念。不同的 API，接口设计风格可以完全不同。DO 也不支持操作语义对于中间组件的可见性。

• DO 中没有使用超文本，响应的内容中只包含对象本身。REST 使用了超文本，可以实现更大粒度的交互，交互的效率比 DO 更高。

• REST 支持数据流和管道，DO 不支持数据流和管道。

• DO 风格通常会带来客户端与服务器端的紧耦合。在三种架构风格之中，DO 风格的耦合度是最大的，而 REST 的风格耦合度是最小的。REST 松耦合的源泉来自于统一接口 + 超文本驱动。

REST 与 RPC 的差别在于：

• REST 支持抽象的工具是资源，RPC 支持抽象的工具是过程。REST 风格的架构建模是以名词为核心的，RPC 风格的架构建模是以动词为核心的。简单类比一下，REST 是面向对象编程，RPC 则是面向过程编程。

• RPC 中没有统一接口的概念。不同的 API，接口设计风格可以完全不同。RPC 也不支持操作语义对于中间组件的可见性。

• RPC 中没有使用超文本，响应的内容中只包含消息本身。REST 使用了超文本，可以实现更大粒度的交互，交互的效率比 RPC 更高。

• REST 支持数据流和管道，RPC 不支持数据流和管道。

• 因为使用了平台中立的消息，RPC 风格的耦合度比 DO 风格要小一些，但是 RPC 风格也常常会带来客户端与服务器端的紧耦合。支持统一接口 + 超文本驱动的 REST 风格，可以达到最小的耦合度。

比较了三种架构风格之间的差别之后，从面向实用的角度来看，REST 架构风格可以为 Web 开发者带来三方面的利益：

• 简单性

采用 REST 架构风格，对于开发、测试、运维人员来说，都会更简单。可以充分利用大量 HTTP 服务器端和客户端开发库、Web 功能测试 / 性能测试工具、HTTP 缓存、HTTP 代理服务器、防火墙。这些开发库和基础设施早已成为了日常用品，不需要什么火箭科技（例如神奇昂贵的应用服务器、中间件）就能解决大多数可伸缩性方面的问题。

• 可伸缩性

充分利用好通信链各个位置的 HTTP 缓存组件，可以带来更好的可伸缩性。其实很多时候，在 Web 前端做性能优化，产生的效果不亚于仅仅在服务器端做性能优化，但是 HTTP 协议层面的缓存常常被一些资深的架构师完全忽略掉。

• 松耦合

统一接口 + 超文本驱动，带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内，相对独立地进化。对于设计面向企业内网的 API 来说，松耦合并不是一个很重要的设计关注点。但是对于设计面向互联网的 API 来说，松耦合变成了一个必选项，不仅在设计时应该关注，而且应该放在最优先位置。

有的读者可能会问：“你说了这么多，REST 难道就没有任何缺点了吗？”当然不是，正如 Fielding 在博士论文中阐述的那样，评价一种软件架构的优劣，不能脱离开软件的具体运行环境。永远不存在适用于任何运行环境的、包治百病的银弹式架构。笔者在前面强调过 REST 是一种为运行在互联网环境中的 Web 应用量身定制的架构风格。REST 在互联网这个运行环境之中已经占据了统治地位，然而，在企业内网运行环境之中，REST 还会面临 DO、RPC 的巨大挑战。特别是一些对实时性要求很高的应用，REST 的表现不如 DO 和 RPC。所以需要针对具体的运行环境来具体问题具体分析。但是，REST 可以带来的上述三方面的利益即使在开发企业应用时，仍然是非常有价值的。所以 REST 在企业应用开发，特别是在 SOA 架构的开发中，已经得到了越来越大的重视。本专栏将有一篇文章专门介绍 REST 在企业级应用中与 SOA 的结合。

到了这里，“REST 究竟是什么”这个问题笔者就解答完了。本文开头那些说法是否正确，笔者还是笑而不语，读者此时应该已经有了自己的判断。在接下来的 REST 系列文章中，我将会为读者澄清一些关于 HTTP 协议和 REST 的常见误解。

参考资料：

Roy Fielding 博士论文英文版

Roy Fielding 博士论文中文版

HTTP/1.1 协议RFC2616、RFC2617

感谢马国耀对本文的策划和审校。