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 – 既存のリソースを変更する
• 削除 – リソースを削除する

リソース識別子

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

ハイパーメディア

「メディア タイプ」またはデータ形式の表現は、リソースの処理方法を定義します。 REST API では、すべてのメディア タイプは JSON に基づいており、ハイパーメディア(ハイパーテキストと呼ばれることもありますが、少し異なります) です。 ハイパーメディアとは、他のメディアへのリンクを持つコンテンツのことです。 アプリケーション状態のエンジンとしてのハイパーメディア (HATEOAS) は、REST アーキテクチャをユニークなものにしています。

注記： Roy Fielding によれば、API が REST API と見なされるためには、ハイパーメディアを使用する必要があります。 しかし、今日では多くの API 設計者が、ハイパーメディアやハイパーテキストを使用していないにもかかわらず、その API を流行語として「REST[ful]」と呼ぶことがよくあります。

自己記述的

リソース表現は自己記述的であることを目指しており、API は独自のコンテキスト内でそれ自体が理解されることを意味します。 自己記述的な表現を使用すると、クライアントはリソースがどのカテゴリに属しているかを知る必要がなくなり、代わりにリソースに関連付けられたメディア タイプに基づいて動作します。

現在、ほとんどの企業は、基本的な機能、革新的な機能、重要な機能を提供するアプリ間の通信に、社内で開発された API とサードパーティの API を使用しています。 これらの API の大部分は REST API です。これは、REST によって義務付けられた特定の通信標準により、安全で効率的かつ信頼性の高い情報交換が可能になるためです。 REST API は任意のプロトコルでも動作します。

REST API は、RESTful Web サービスが応答を送信する前に要求を認証するため、安全です。 ユーザー ID を確認するために、REST API は HTTP 認証 (基本トークンとベアラー トークンの両方)、API キー、およびログイン アクセス用の OAuth を使用します。

REST API のその他の利点は次のとおりです。

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

REST は依然としてクライアント アプリケーションとサーバー アプリケーションを接続するための最も一般的なアーキテクチャですが、 GraphQL (2012 年に Facebook によって開発され、2015 年にオープンソース化) は REST の代替として設計されました。 GraphQL API は、必要なすべてのデータが単一のリクエストで標準化された形式で要求されるため、REST API よりも効率的ですが、REST が優れている領域はまだいくつかあります。 GraphQL は学習曲線が急峻で、REST に比べてキャッシュ性がはるかに低くなります。 さらに、アプリケーションはリソースによって駆動されることが多く、GraphQL のようなクエリ言語は必要ありません。 とはいえ、それぞれのモデルには長所と短所があり、組織は両方を使用することを選択できます。