REST（Representational State Transfer）は、ワールドワイドウェブ（ World Wide Web）のアーキテクチャ設計を記述し、開発を導くために考案されたソフトウェアアーキテクチャスタイルです。RESTは、Webのような分散型インターネット規模のハイパーメディアシステムのアーキテクチャがどのように動作するべきかに関する一連の制約を定義します。RESTアーキテクチャスタイルは、統一されたインターフェース、コンポーネントの独立したデプロイメント、コンポーネント間の相互作用のスケーラビリティ、そしてキャッシュを促進する階層化アーキテクチャの構築を重視しています。これにより、ユーザーが感じるレイテンシの削減、セキュリティの強化、そしてレガシーシステムのカプセル化が促進されます。[1]

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

原理

「表現的状態転送（Representational State Transfer） 」という用語は、2000年にコンピュータ科学者ロイ・フィールディングによって博士論文で導入・定義されました。これは、サーバーがリソース（今日では多くの場合HTML文書）の表現で応答し、そのリソースにはシステムの状態を変更するためのハイパーメディアリンクが含まれることを意味します。このようなリクエストは、今度はリソースの表現を受け取り、これを繰り返します。

重要な結論として、必要な識別子は最初に要求されたリソースの識別子のみであり、他のすべての識別子は自動的に検出されるという点が挙げられます。これは、これらの識別子がクライアントに事前に通知することなく変更される可能性があることを意味し、クライアントとサーバーは本質的に疎結合である必要があります。

歴史

ロイ・フィールディング氏がOSCON 2008で講演

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

W3CとIETFのワーキンググループは共同で、 Webの3つの主要な標準であるURI、HTTP、HTMLの正式な記述を作成する作業を開始しました。Roy Fieldingはこれらの標準（具体的にはHTTP 1.0と1.1、URI）の作成に携わり、その後6年間でRESTアーキテクチャスタイルを作成し、Webのプロトコル標準に対する制約をテストし、アーキテクチャの改善を定義する手段として使用し、アーキテクチャの不一致を特定しました。Fieldingは、2000年にカリフォルニア大学アーバイン校で博士論文「Architectural Styles and the Design of Network-based Software Architectures」[1] [5]でRESTを定義しました。

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

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

建築特性

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

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

RESTアーキテクチャスタイルで表現された概念のエンティティ・リレーションシップ・モデル

RESTアーキテクチャスタイルの制約は、以下のアーキテクチャ特性に影響を与えます。[1] [7]

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

アーキテクチャ上の制約

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

正式なREST制約は次のとおりです。[10]

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

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

統一インターフェース制約は、あらゆるRESTfulシステムの設計において基本的な要素です。[1]統一インターフェース制約はアーキテクチャを簡素化・分離し、各部分が独立して進化することを可能にします。この統一インターフェースには以下の4つの制約があります。

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

分類モデル

REST APIをREST設計のさまざまな原則に従って分類するのに役立ついくつかのモデルが開発されています。

参照

参考文献

  1. ^ abcdef Fielding, Roy Thomas (2000). 「第5章: Representational State Transfer (REST)」.アーキテクチャスタイルとネットワークベースソフトウェアアーキテクチャの設計(Ph.D.). カリフォルニア大学アーバイン校. 2021年5月13日時点のオリジナルよりアーカイブ。2004年8月17日閲覧。
  2. ^ Fielding, Roy T. (2008年10月20日). 「REST APIはハイパーテキスト駆動型でなければならない」roy.gbiv.com. 2010年3月18日時点のオリジナルよりアーカイブ。2016年7月6日閲覧。
  3. ^ クルドリー、ニック（2012年）『メディア、社会、世界：社会理論とデジタルメディア実践』ロンドン：ポリティ・プレス、p.2、ISBN 9780745639208. 2024年2月27日時点のオリジナルよりアーカイブ。2021年6月9日閲覧。
  4. ^ ab Fielding, Roy Thomas (2000). 「第6章 経験と評価」.アーキテクチャスタイルとネットワークベースソフトウェアアーキテクチャの設計(Ph.D.). カリフォルニア大学アーバイン校. 2023年3月26日時点のオリジナルよりアーカイブ。 2023年6月21日閲覧。
  5. ^ 「FieldingがREST用語の定義について議論」 groups.yahoo.com. 2015年11月5日時点のオリジナルよりアーカイブ。 2017年8月8日閲覧。
  6. ^ Fielding, Roy Thomas (2000). 「第4章 Webアーキテクチャの設計：問題点と考察」.アーキテクチャスタイルとネットワークベースソフトウェアアーキテクチャの設計(Ph.D.). カリフォルニア大学アーバイン校. 2025年1月28日閲覧。{{cite thesis}}: CS1 maint: url-status (リンク)
  7. ^ ab Erl, Thomas; Carlyle, Benjamin; Pautasso, Cesare; Balasubramanian, Raj (2012). "5.1". SOA with REST: Principles, Patterns & Constraints for Building Enterprise Solutions with REST . Upper Saddle River, New Jersey: Prentice Hall. ISBN 978-0-13-701251-0。
  8. ^ ab Fielding, Roy Thomas (2000). 「第2章 ネットワークベースのアプリケーションアーキテクチャ」.アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計(Ph.D.). カリフォルニア大学アーバイン校. 2014年12月16日時点のオリジナルよりアーカイブ。 2014年4月12日閲覧。
  9. ^ リチャードソン、レナード、ルビー、サム (2007). RESTful Web Services . セバストーポル、カリフォルニア州: オライリーメディア. ISBN 978-0-596-52926-0。
  10. ^ 「REST APIとは？」www.visual-paradigm.com . 2024年2月24日時点のオリジナルよりアーカイブ。2024年2月24日閲覧。
  11. ^ Gupta, Lokesh (2018年6月2日). 「REST HATEOAS」. REST APIチュートリアル. RESTfulAPI.net. 2019年4月7日時点のオリジナルよりアーカイブ。2019年3月10日閲覧。
  12. ^ 「HTTP APIの分類」algermissen.io . 2023年1月29日時点のオリジナルよりアーカイブ。2023年1月29日閲覧。
  13. ^ Ivan Salvadori、Frank Siqueira (2015年6月). 「セマンティックRESTful Web APIの成熟度モデル」.カンファレンス: Web Services (ICWS), 2015 IEEE International Conference OnAt . ニューヨーク. 2024年2月27日時点のオリジナルよりアーカイブ。 2020年12月14日閲覧– ResearchGate経由。


さらに読む

  • パウタッソ、チェーザレ、ワイルド、エリック、アラルコン、ローザ（2014）、REST：高度な研究トピックと実践的アプリケーション、シュプリンガー、ISBN 9781461492986
  • Pautasso, Cesare; Zimmermann, Olaf; Leymann, Frank (2008年4月)、「Restful Webサービス vs. "big"' Webサービス」、第17回国際ワールドワイドウェブ会議論文集、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). 「リチャードソン成熟度モデル：RESTの栄光へのステップ」martinfowler.com . 2017年6月26日閲覧。