REST APIとは何か

RESTはREpresentational State Transferの略で、2000年にコンピュータ サイエンティストのRoy Fielding氏によって作られたアーキテクチャ スタイルです。RESTによって開発者に柔軟性がもたらされるため、マイクロサービス アーキテクチャでアプリケーションを接続するのに理想的です。

RESTでは、アプリケーションとAPIがRESTfulであると見なされるために従う必要のある6つの制約条件が定義されています。

• 統一されたインターフェイス
• クライアント/サーバ アーキテクチャ
• ステートレス性
• 階層化システム
• キャッシュ可能性
• オンデマンドのコード

これらの制約条件の詳細については、Wikipediaを参照してください。

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

インターフェイスを統一すると、全体的なシステム アーキテクチャが簡素化され、やり取りの可視性が向上します。また、情報が標準的な形式で転送されることを保証する特定の要件もあります。

以下の4つの制約条件によって、RESTインターフェイスを統一することができます。

• 各リソースにはURIなどの一意の識別子があり、メッセージでのリソースの表現はサーバの内部表現とは異なる
• リソース表現に、クライアントがリソースの状態を変更または削除するために十分な情報が含まれている
• 各メッセージに、処理方法を説明するのに十分な情報が含まれている
• サーバは、使用可能なリソースをクライアントにハイパーリンクで通知するため、クライアントはサーバ内部について知る必要がない

クライアント/サーバ

クライアント/サーバ アーキテクチャは、クライアント、サーバ、リソースで構成されます。ユーザー インターフェイス（クライアントによって制御）をデータ ストレージ（サーバによって制御）から分離することは、クライアント コンポーネントとサーバ コンポーネントが自律的に発展できることを意味します。また、複数のプラットフォーム間のクライアント ユーザー インターフェイスの移植とサーバの拡張が簡素化されます。

インターネット上のクライアント/サーバのやり取りは、HTTPを介して行われます。

ステートレス性

クライアント/サーバ通信におけるステートレス性とは、サーバがクライアントまたはクライアントと確立されたセッションに関する情報を一切保存しないことを意味します。各メッセージ内のセッション関連情報に対するクライアントの表現は、以前のメッセージからのコンテキストがなくても単独でサーバが理解できる必要があります。これによってサーバの負荷が軽減され、大容量アプリケーションのパフォーマンスが向上します。

階層化システム

クライアントは、サーバに直接接続しているのか、リバース プロキシやロード バランサなどの仲介デバイスに接続しているのかを知る必要がありません（通常は区別できません）。仲介デバイスは拡張性の向上を支援し、セキュリティを管理して、サーバがビジネス ロジックだけを担うことができるようにします。

キャッシュ可能性

HTTPクライアントと仲介デバイスは、サーバのレスポンスをキャッシュしてサーバの負荷を軽減し、エンド ユーザーへのデータ配信速度を向上させることができます。サーバは、レスポンスがキャッシュ可能かどうかを示す必要があります。キャッシュ不可能な場合は、後続のエンドユーザーのリクエストに対するレスポンスが正しく最新である（「古くなっている」可能性がない）ことが保証されます。クライアントは一意の識別子であるURLによってリソースにアクセスするため、クライアントはリソース レベルで何をキャッシュすべきかを判断できます。キャッシュ機能を活用することで、クライアントは基本的に一度取得したリソースを再使用することができます。

オンデマンドのコード

オンデマンドのコードとは、サーバがクライアントの機能を一時的に拡張またはカスタマイズするために実行可能コードを送信できることを意味します。これによって、クライアントはその機能を実装する必要がなくなります。オンデマンドのコードは、オプションの制約条件です。

RESTで最も重要なデータ表現または抽象化がリソースです。RESTリソースは、デジタル ドキュメントから非デジタル オブジェクトまで、あらゆる種類の抽象化された情報になります。任意の時点でのリソースの状態をリソース表現と言います。

リソース表現には次の3つの要素があります。

• データ
• メタデータ
• ハイパーメディア リンク

REST APIは、一意のURIでアクセスできる連結されたリソースの集合（リソース モデル）で構成されます。クライアントは、レスポンス内の関連リソースとURIにリンクすることによって柔軟な機能を実現できます。一般に、REST APIへのリクエストはHTTP GETリクエストの形式で送信されます。多くの場合、サーバはレスポンスの形式をJSONに設定します。

以下のHTTPリクエスト メソッドは、示されている方法でリソースを操作するために使用されます。

• GET – リソースをロードする
• POST – 新しいリソースを作成する
• PUT – 既存のリソースを変更する
• DELETE – リソースを削除する

リソース識別子

RESTアーキテクチャ スタイルでは、クライアントとサーバのやり取りに関連する各リソースをリソース識別子で一意に指定します。

ハイパーメディア

「メディア タイプ」、つまりデータ形式の表現によって、リソースの処理方法が定義されます。REST APIでは、すべてのメディア タイプがJSONに基づいており、ハイパーメディアになります（ハイパーテキストと呼ばれることもありますが、若干異なります）。ハイパーメディアは、他のメディアへのリンクを含むコンテンツです。Hypermedia as the Engine of Application State（HATEOAS）は、RESTアーキテクチャを特徴付けるものです。

注：Roy Fielding氏によると、APIがREST APIであると見なされるには、ハイパーメディアを使用する必要があります。ただし現在、多くのAPI設計者は、ハイパーメディア/ハイパーテキストを使用していなくても、業界用語としてAPIを「REST[ful]」と呼んでいます。

自己記述性

リソース表現は自己記述的であること、つまり、APIがそのコンテキスト内で自らの内容を伝えることを目標にしています。自己記述的な表現を使用すると、クライアントはリソースがどのカテゴリに属しているかを知る必要がなく、代わりにリソースと関連するメディア タイプに基づいて機能します。

今日では、ほとんどの企業が、基本的、革新的、かつ重要な機能を提供するアプリケーション間の通信に、社内開発のAPIやサードパーティのAPIを使用しています。これらのAPIの大部分がREST APIです。これは、RESTで要求される特定の通信規格を使用すると、連携が容易で安全かつ効率的で信頼性の高い情報交換が可能になるためです。REST APIはどのようなプロトコルでも機能します。

また、RESTful Webサービスはレスポンスが送信される前にリクエストを認証するため、REST APIは安全です。ユーザーIDを検証するために、REST APIはHTTP認証（BasicとBearer Token）、APIキー、およびログイン アクセス用のOAuthを採用しています。

REST APIにはその他にも以下のメリットがあります。

• システムの拡張性 – RESTによってクライアントとサーバ間のやり取りが最適化されるため、REST APIは効率的に拡張できます。RESTfulのステートレス性の制約条件によって、サーバで以前のリクエストに関する情報を保存する必要がないため、サーバの負荷が軽減されます。また、キャッシュ可能性によって、ボトルネックを引き起こす可能性のあるクライアント/サーバ間のやり取りの数が低減されます。その結果、拡張性のある高性能のAPIになります。
• 開発者のための柔軟性 – 多くのエンタープライズ アプリケーションは、社内のAPIまたはサードパーティのAPIと通信する必要があります。RESTful Webサービスは、クライアントとサーバ間の分離をサポートしているため、それぞれ独立して発展できます。
• 技術的な独立性 – REST APIは、対応するアプリケーションの開発に使用されたプログラミング言語およびフレームワークに依存していません。クライアント アプリケーションとサーバ アプリケーションは言語やフレームワークを共有する必要がなく、それらを変更してもAPI設計や通信プロセスに影響を与えることはありません。

APIを使用することにより既存のサービスが使用可能となり、業務効率や開発スピードの向上に繋がります。

RESTがクライアント アプリケーションとサーバ アプリケーションを接続するための最も一般的なアーキテクチャであるのに対して、GraphQL（2012年にFacebookが開発、2015年にオープン ソース化）は、RESTに代わるものとして設計されました。GraphQL APIは、必要なすべてのデータが1つのリクエストで標準化された形式で要求されるため、REST APIよりも効率的ですが、RESTの方が優れている面があります。GraphQLでは多くのことを覚える必要があり、RESTよりもはるかにキャッシュ可能性が低くなります。また、多くの場合で、アプリケーションはリソースによって駆動されるため、GraphQLのようなクエリ言語は必要ありません。とは言え、各モデルにはメリットとデメリットがあるため、組織は両方を使用することもできます。