深さ探査REST（2）：真のRESTアーキテクチャスタイルを理解します

記事の転載アドレスします。https：//www.infoq.cn/article/understanding-restful-style/、そのような元の記事への参照のアドレスをマークしてください

プライマー

あなたは「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において、略号の各々は、建築様式内部楕円を示し、各矢印の言葉は、サイドアーキテクチャ制約を表します。

6をしているが、最も重要な建築制約のRESTアーキテクチャ・スタイル：

• クライアント - サーバー（クライアントサーバー）

レスポンスフォーム - コミュニケーションだけで一方的に、クライアント側で要求のパフォーマンスを開始することができます。

• ステートレス（ステートレス）

セッション状態（セッション状態）は、クライアントによって維持されるすべての通信のために責任を負わなければなりません。

• キャッシュ（キャッシュ）

コンテンツは、ネットワークの効率を向上させるために、通信チェーンのどこかに応答してキャッシュすることができます。

• 統一されたインターフェイス（統一されたインタフェース）

コンポーネント間の通信リンクは、相互作用の視認性を向上させるために統一されたインタフェースを介して互いに通信します。

• レイヤードシステム（レイヤーシステム）

コンポーネントの動作を制限することによって、層アーキテクチャは、いくつかのレベルに分解される（すなわち、各コンポーネントのみと相互作用する隣接層は「見る」ことができます）。

• オンデマンドコード（コード・オン・デマンド、オプション）

、拡張するためのクライアントの機能（たとえば、Javaアプレット、FlashやJavaScriptなど）いくつかのコードをダウンロードして実行することでサポート。

以下に示すように、RESTアーキテクチャ・スタイルの紙に派生：

図2：RESTアーキテクチャスタイル（アートワークはここからダウンロードすることができます）

 

RESTアーキテクチャ・スタイルの例として、HTTP / 1.1プロトコルアーキテクチャが、その構造は下記のように：

図3：ビューベースのプロセスRESTアーキテクチャ（元はここからダウンロードすることができます）

3つの平行な（a、bおよびc）の途中でユーザ対話エージェント。ユーザエージェントクライアント接続キャッシュは、クライアントの構成プロパティに応じて、要求を満たすことができず、各リソース識別子用のコネクタは、各要求は、ソースリソースにルーティングされます。（a）の要求はホームエージェントに送信され、エージェントはその後、ゲートウェイは、オブジェクト要求を通じて満たすために、要求の送信元サーバー、パッケージによる内部リソースサーバーを要求を転送し、検索はDNSを介してキャッシュゲートウェイを見つけアクセスエージェント（オブジェクト・リクエスト・ブローカー）アーキテクチャが定義されました。（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

 

文章转载地址：https://www.infoq.cn/article/understanding-restful-style/，如引用请标注文章原地址