休む

REST ( Re presentation state transfer ) は、ワールドワイドウェブのアーキテクチャの設計と開発を導くために作成されたソフトウェアアーキテクチャスタイルです。REST は、ウェブなどの分散型インターネット規模のハイパーメディアシステムのアーキテクチャがどのように動作するべきかについての一連の制約を定義します。REST アーキテクチャスタイルは、統一されたインターフェイス、コンポーネントの独立した展開、コンポーネント間の相互作用のスケーラビリティ、およびキャッシュを促進する階層化アーキテクチャの作成を重視しており、これによりユーザーが感じる待ち時間を減らし、セキュリティを強化し、レガシーシステムをカプセル化します。^[1]

REST は、ソフトウェア業界全体で、ステートレスで信頼性の高いWeb ベースのアプリケーションを作成するために採用されています。REST アーキテクチャの制約に準拠したアプリケーションは、非公式にはRESTfulと説明されることがあります。ただし、この用語は、 HTTPベースのAPIの設計や、リソースが応答する「動詞」( HTTP メソッド)に関するベスト プラクティスと広く考えられているものと関連付けられることが多く、元々の REST とはほとんど関係がなく、概念と矛盾することさえあります。^[2]

表現状態転送という用語は、2000 年にコンピューター科学者Roy Fieldingが博士論文で導入し定義しました。これは、サーバーがリソースの表現 (現在ではHTML、XML、またはJSONドキュメントがほとんど) で応答し、そのリソースにはシステムの状態を変更するためにたどることができるハイパーメディアリンクが含まれることを意味します。このような要求は、リソースの表現を順番に受信します。

重要な結果は、知っておく必要がある識別子は、要求された最初のリソースの識別子のみであり、他のすべての識別子が検出されるということです。つまり、これらの識別子は、事前にクライアントに通知する必要なく変更でき、クライアントとサーバーの間の結合は緩いものになります。

ウェブが日常的に使われるようになったのは、一般向けのウェブサイトが利用可能になり始めた1993年から1994年にかけてでした。^[3]当時、ウェブのアーキテクチャに関する記述は断片的であり、業界内ではウェブインターフェースプロトコルの標準に同意するよう圧力がかかっていました。たとえば、プロキシをサポートするために通信プロトコル (HTTP) にいくつかの実験的な拡張機能が追加され、さらに多くの拡張機能が提案されていましたが、これらの変更の影響を評価するための正式なウェブアーキテクチャが必要でした。^[4]

W3CとIETF のワーキング グループは共同で、Web の 3 つの主要な標準であるURI、HTTP、HTMLの正式な記述を作成する作業を開始しました。Roy Fielding はこれらの標準 (具体的にはHTTP 1.0 と 1.1、および URI) の作成に携わり、その後 6 年間で REST アーキテクチャ スタイルを作成し、Web のプロトコル標準に対する制約をテストし、アーキテクチャの改善を定義する手段として使用して、アーキテクチャの不一致を特定しました。Fielding は、2000 年にカリフォルニア大学アーバイン校で博士論文「アーキテクチャ スタイルとネットワークベースのソフトウェア アーキテクチャの設計」^{[1] [5]}で REST を定義しました。

REST アーキテクチャ スタイルを作成するために、Fielding は、世界的な導入を可能にするために参入障壁を低くする必要があるなど、世界規模のネットワーク ベースのアプリケーションを作成するときに適用される要件を特定しました。また、ネットワーク ベースのアプリケーションの既存のアーキテクチャ スタイルを多数調査し、キャッシュやクライアント サーバー機能など他のスタイルと共有される機能と、リソースの概念など REST に固有の機能を特定しました。Fielding は、現在の実装の既存のアーキテクチャを分類し、Web の動作とパフォーマンスの要件の中心となる側面を特定しようとしていました。

アーキテクチャ スタイルは、その性質上、特定の実装とは独立しており、REST は Web 標準の開発の一環として作成されましたが、Web の実装は REST アーキテクチャ スタイルのすべての制約に従っているわけではありません。無知や見落としにより不一致が生じる可能性がありますが、REST アーキテクチャ スタイルが存在することで、標準化される前に不一致を識別できます。たとえば、Fielding は、URI にセッション情報を埋め込むことは、共有キャッシュやサーバーのスケーラビリティに悪影響を与える可能性がある REST の制約違反であると特定しました。HTTPクッキーも、ブラウザーのアプリケーション状態と同期しなくなり、信頼性が低下する可能性があるため、REST 制約^[4]に違反していました。また、不透明なデータが含まれているため、プライバシーとセキュリティに懸念が生じる可能性があります。

REST アーキテクチャ スタイルは、ネットワーク ベースのアプリケーション、具体的にはクライアント サーバー アプリケーション向けに設計されています。しかし、それ以上に、インターネット規模の使用向けに設計されているため、大規模な導入を容易にするために、ユーザー エージェント(クライアント) とオリジン サーバー間の結合は可能な限り緩くする必要があります。

クライアントとサーバーの強力な分離と、統一されたアドレス指定プロトコルを使用したテキストベースの情報転送により、拡張性、無秩序なスケーラビリティ^[要出典]、コンポーネントの独立した展開、大規模なデータ転送、コンテンツ リーダー、コンテンツ作成者、開発者にとっての参入障壁の低さなど、Web の要件を満たす基礎が提供されました。

RESTアーキテクチャスタイルの制約は、以下のアーキテクチャ特性に影響します。^{[1] [6]}

• コンポーネント間の相互作用におけるパフォーマンスは、ユーザーが認識するパフォーマンスとネットワーク効率の主要な要因となる可能性がある。^[7]
• 多数のコンポーネントとコンポーネント間の相互作用をサポートできるスケーラビリティ。
• 統一されたインターフェースのシンプルさ。
• 変化するニーズを満たすためのコンポーネントの変更可能性（アプリケーションの実行中でも可能）。
• サービスエージェントによるコンポーネント間の通信の可視性。
• プログラム コードをデータとともに移動することによるコンポーネントの移植性。
• コンポーネント、コネクタ、またはデータに障害が発生した場合でも、システムレベルで障害に対する耐性の信頼性。^[7]

RESTアーキテクチャスタイルは、6つのガイドラインとなる制約を定義しています。^{[6] [8]}これらの制約がシステムアーキテクチャに適用されると、パフォーマンス、スケーラビリティ、シンプルさ、変更可能性、可視性、移植性、信頼性などの望ましい非機能特性が得られます。 ^[1]

正式なREST制約は以下のとおりです。^[9]

• クライアント/サーバー – クライアントは明確に定義されたインターフェースによってサーバーから分離されています
• ステートレス – 特定のクライアントは、クライアントが「休止状態」のときにサーバー ストレージを消費しません。
• キャッシュ – レスポンスはキャッシュ可能であることを示す
• 統一されたインターフェース
• 階層化システム – クライアントは通常、エンドサーバーに直接接続されているのか、それとも途中の仲介サーバーに接続されているのかを判断できません。
• オンデマンドコード（オプション） - サーバーは、標準の仮想マシン内で実行できるロジックをクライアントに転送することで、クライアントの機能を一時的に拡張またはカスタマイズできます。

統一インターフェース制約は、あらゆるRESTfulシステムの設計の基本です。^[1]統一インターフェース制約は、アーキテクチャを簡素化および分離し、各部分が独立して進化できるようにします。この統一インターフェースの4つの制約は次のとおりです。

• リクエスト内のリソース識別: 個々のリソースは、 URI を使用してリクエスト内で識別されます。リソース自体は、クライアントに返される表現とは概念的に分離されています。たとえば、サーバーはデータベースからデータをHTML、XML、またはJSONとして送信できますが、これらはいずれもサーバーの内部表現ではありません。
• 表現によるリソース操作: クライアントが、添付されたメタデータを含むリソースの表現を保持している場合、リソースの状態を変更または削除するのに十分な情報が得られます。
• 自己記述型メッセージ: 各メッセージには、そのメッセージの処理方法を説明するのに十分な情報が含まれています。たとえば、どのパーサーを呼び出すかはメディアタイプによって指定できます。^[1]
• アプリケーション状態のエンジンとしてのハイパーメディア ( HATEOAS ) – REST アプリケーションの初期 URI にアクセスすると (人間の Web ユーザーが Webサイトのホームページにアクセスするのと同様)、REST クライアントはサーバーが提供するリンクを動的に使用して、必要なすべての利用可能なリソースを検出できるようになります。アクセスが進むにつれて、サーバーは現在利用可能な他のリソースへのハイパーリンクを含むテキストで応答します。サーバーの構造に関する情報をクライアントにハードコードする必要はありません。^[10]

REST APIをREST設計のさまざまな原則に準拠しているかどうかに応じて分類するのに役立ついくつかのモデルが開発されています。

• リチャードソン成熟モデル
• HTTPベースAPIの分類^[11]
• WS3成熟度モデル^{[ 12]}

• クリーンURL  – ウェブサイトの使いやすさを向上させることを目的としたURL
• コンテンツ配信ネットワーク – ボトルネックを解決するインターネットエコシステムのレイヤー
• ドメイン アプリケーション プロトコル(DAP)
• URI スキームのリスト – IANA によって割り当てられた名前空間識別子
• マイクロサービス – コンピュータアプリケーションの構築に使用される疎結合サービスの集合
• RESTful API記述言語の概要 – コンピュータネットワークインターフェースの記述フォールバックとしてウィキデータの説明を表示するページ
• リソース指向アーキテクチャ – ソフトウェア設計におけるアーキテクチャパターン
• リソース指向コンピューティング – ソフトウェア設計におけるアーキテクチャパターン
• サービス指向アーキテクチャ – ソフトウェア設計におけるアーキテクチャパターン
• Web 指向アーキテクチャ – ソフトウェア設計におけるアーキテクチャ パターン
• ウェブサービス – インターネットを介して電子機器間で提供されるサービスリダイレクト先の簡単な説明を表示するページ

• パウタッソ、チェーザレ、ワイルド、エリック、アラルコン、ローザ（2014）、REST：高度な研究トピックと実用的なアプリケーション、Springer、ISBN 9781461492986
• Pautasso, Cesare、Zimmermann, Olaf、Leymann, Frank (2008 年 4 月)、「Restful Web サービスと「big」Web サービス」、第 17 回 World Wide Web 国際会議の議事録、pp. 805–814、doi :10.1145/1367497.1367606、ISBN 9781605580852、S2CID  207167438
• Ferreira、Otavio (2009 年 11 月)、Semantic Web Services: A RESTful Approach、IADIS、ISBN 978-972-8924-93-5
• Fowler, Martin (2010-03-18). 「Richardson 成熟度モデル: REST の栄光へのステップ」. martinfowler.com . 2017-06-26に閲覧。