導入
REST ( Representational State Transfer ) は、World Wide Web のような分散システム用のアプリケーションを構築する方法です。この用語は 2000 年にロイ フィールディングによって造られました。
REST はプロトコルやフォーマットではなく、アーキテクチャ スタイルであり、Web の本来のアーキテクチャ スタイルです。
このアーキテクチャでは、コンポーネントはリソースの表現を使用してリソースを読み取るか変更します。リソースは名前を付けられるものであり、時間の経過とともに変化する可能性があります。表現はバイトのシーケンスであり、メタデータ (名前/値のシーケンス) を伴う場合があります。コンポーネントはアクターであり、チャネルによって他のコンポーネントやリソースに接続され、ステートレスな対話が可能になります。
このアーキテクチャの Web への適用は、いくつかの簡単な原則に基づいて理解できます。
- URI は重要です。リソースに名前を付けて識別するには、URI がわかれば十分です。
- HTTP は、必要なすべての操作 (基本的に
GET、POST、PUT、およびDELETE) を提供します。 - 各操作は独立しています。状態はありません。
- ハイパーメディア標準の使用: 他のリソースへのリンクを許可し、REST アプリケーションでのナビゲーションを保証する HTML または XML がよく使用されます。ただし、JSON などの他の形式の使用も可能です。
RESTの説明
このアーキテクチャ スタイルは、人間のユーザー向けのアプリケーションの作成に限定されません。マシン間の通信を目的とした Web サービスを使用したサービス指向アーキテクチャの作成に使用されることが増えています。 REST は、RPC アーキテクチャ スタイルおよびほとんどのSOAPユースケースの代替であり (REST スタイルのサービス指向アーキテクチャを想像することもできますが、SOAPテクノロジを使用します)、アートワークの実装がより簡単であると考えられています。フィールディングの REST 原則に従ったシステムは、多くの場合RESTfulと呼ばれます。
これは、クライアント(ブラウザーまたは Web サービス クライアント ライブラリ) の状態とアプリケーションの状態 (またはサーバーによって維持されるリソースの状態) の違いを強調しています。
SOAP や XML-RPC のように、リクエストに対する応答が XML である場合が多いとしても、これは必須ではありません。 JSON 応答またはシリアル化された Java オブジェクトは完全に受け入れられます。
利点
Roy Fielding の論文では、 Web アプリケーション アーキテクチャの他のスタイルと比較して、このアーキテクチャ スタイルの利点が明記されています。とりわけ以下を引用しましょう。
- リンクがより適切に構造化され、普遍的な方法で作成されるため、アプリケーションの保守が簡単になります。リンクはアプリケーション状態のエンジンです。
- サーバー上でクライアント状態管理が行われないため、メモリ消費量が削減され、簡素化が図られるため、多数の同時リクエストに応答する能力が向上します。
- サーバー上にクライアント状態管理がないため、リクエストを複数のサーバーに分散できます。クライアント セッションを特定のサーバー上で維持する必要がなく（ロードバランサーのスティッキー セッションを介して）、すべてのサーバーに伝播する必要もありません（セッションの鮮度を維持しながら）。問題）。これにより、スケーラビリティとフォールト トレランスも向上します (サーバーを簡単に追加して処理能力を高めたり、別のサーバーを置き換えたりできます)。
- プロトコルを前提としない SOAP とは対照的に、エンベロープとヘッダーを利用した HTTP プロトコルの使用: SOAP は、それをホストするネットワーク プロトコル(主に HTTP) 内で、エンベロープ、ヘッダー、およびドキュメントを介してプロトコルを再発明します。 。したがって、ネットワーク インフラストラクチャ (特に、パフォーマンスを向上させるためにサーバー側のキャッシュをサポートするプロキシ) によって管理される HTTP 特性の恩恵を受けません。
- リソースの代表として URI を使用すると、キャッシュ サーバーの実装が可能になります。
短所
REST の主な欠点は、クライアントがリクエストを正常に完了するために必要なすべてのデータをローカルに保持する必要があるため、ネットワーク帯域幅の消費量が増加することです。 REST Web アプリケーションを、データベースや Cookie などのセッション中のデータの永続性を確保する外部サービスに結合することが可能であれば、そのようなサービスを使用して、関連するデータを管理することを検討することもできます。クライアントが開いたセッションに接続すると、REST の理念に違反します。 REST では、クライアント ブラウザのメモリ内に存在するJavascriptでエンコードされたテーブルの使用が優先されます。
DELETEなどのメソッドでデータを送信する HTML フォームの使用は、ほとんどのブラウザーでは理解できません。この問題を解決するために、データ送信方法のタイプをアプリケーションに送信する隠しフィールドを使用してこの動作をエミュレートします。
さらに、多くのアプリケーションは、REST アーキテクチャの制約をすべて厳密に尊重しているわけではありませんが、主に REST アーキテクチャからインスピレーションを得ています。
