REST APIとは

AREST APIとは、インターネットなどのネットワークを介して2つのシステム（クライアントとサーバー）間でデータを表現し、通信するためのアプリケーションプログラミングインターフェース（API）の一種で、Representational State Transfer（REST）モデルに準拠しています。REST APIは、社内アプリケーションとサードパーティ製アプリケーション間の情報交換をサポートし、複数のエンドポイントをアプリケーションエコシステムに統合できるようにします。

注：厳密には、RESTはモデルを指す用語であり、そのモデルに準拠するAPIを表す形容詞ではありません。そのようなAPIの正しい呼称はRESTful APIです。ただし、REST APIの方が一般的に使用されているため、この記事でもこの呼称を使用します。

RESTとは

前述のとおり、RESTはRepresentational State Transferの略で、コンピューター科学者のRoy Fieldingが2000年に考案したアーキテクチャスタイルです。RESTは開発者に柔軟性をもたらすため、マイクロサービスアーキテクチャでのアプリケーション間の接続に適しています。

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

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

これらの制約について詳しくは、Wikipediaをご覧ください。

統一インターフェース

統一インターフェースにより、システム全体のアーキテクチャが簡素化され、インタラクションの可視性が向上します。また、情報が標準形式で転送されるようにするための具体的な要件も定められています。

RESTインターフェースの統一性は、次の4つの制約によって実現されます。

各リソースにはURIなどの一意の識別子があり、メッセージ内のリソース表現は、サーバー内部の表現とは分離されています
リソース表現には、クライアントがリソースの状態を変更または削除するために十分な情報が含まれる
各メッセージには、その処理方法を示すために十分な情報が含まれています
サーバーはハイパーリンクを使用して、利用可能なリソースをクライアントに通知するため、クライアントがサーバーの内部構造を把握する必要はありません

クライアントサーバー

クライアントサーバーアーキテクチャは、クライアント、サーバー、リソースで構成されます。クライアントが制御するユーザーインターフェースと、サーバーが制御するデータストレージを分離することで、クライアントとサーバーの各コンポーネントを個別に進化させることができます。また、クライアントのユーザーインターフェースを複数のプラットフォームに移植しやすくなり、サーバーの拡張性も高まります。

インターネット上では、クライアントとサーバーはHTTPを介して通信します。

ステートレス性

クライアントとサーバー間の通信におけるステートレスとは、サーバーがクライアントや、そのクライアントとの間で確立されたセッションに関する情報を一切保存しないことを意味します。クライアントは、各メッセージにセッション関連情報を含め、サーバーが過去のメッセージのコンテキストを参照せずに、そのメッセージだけで内容を理解できるようにする必要があります。これによりサーバーの負荷が軽減され、大量の処理を伴うアプリケーションのパフォーマンスが向上します。

階層化システム

クライアントは、サーバーに直接接続しているのか、リバースプロキシやロードバランサーなどの中間サーバーに接続しているのかを把握する必要はありません（通常は判別もできません）。中間サーバーはスケーラビリティの向上に役立ち、セキュリティ処理を担うこともできるため、サーバーはビジネスロジックのみに専念できます。

キャッシュ可能性

HTTPクライアントおよび中継サーバーは、サーバーからのレスポンスをキャッシュすることで、サーバーの負荷を軽減し、エンドユーザーへのデータ配信を高速化できます。サーバーは、レスポンスがキャッシュ可能かキャッシュ不可かを示す必要があります。キャッシュ不可にすることで、以降のエンドユーザーリクエストに対するレスポンスが正確かつ最新であり、古い情報となる可能性がないことを保証します。クライアントは一意の識別子であるURLを使用してリソースにアクセスするため、リソース単位でキャッシュ対象を判断できます。

Code-on-Demand

Code-on-Demandとは、サーバーが実行可能コードを送信してクライアントの機能を一時的に拡張またはカスタマイズできる仕組みです。これにより、クライアント側でその機能を実装する必要がなくなります。Code-on-Demand制約は任意です。

リソースとは

RESTにおいて最も重要なデータ表現または抽象化は「リソース」です。RESTリソースは、デジタル文書から非デジタルオブジェクトまで、抽象化されたあらゆる種類の情報を指します。ある時点におけるリソースの状態は「リソース表現」と呼ばれます。

リソース表現は、次の3つの要素で構成されます。

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

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

リソースに対して指定された操作を実行するには、次のHTTPリクエストメソッドを使用します。

GET – リソースを読み込む
POST – 新しいリソースを作成
PUT – 既存のリソースを変更
DELETE – リソースを削除

リソース識別子

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

ハイパーメディア

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

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

自己記述的

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

REST APIのメリット

現在、ほとんどの企業では、基本的な機能から革新的かつ重要な機能までを提供するアプリ間の通信に、社内開発のAPIやサードパーティAPIを使用しています。その大半はREST APIです。RESTで規定された特定の通信標準により、安全で効率的かつ信頼性の高い情報交換が可能になるためです。また、REST APIはあらゆるプロトコルに対応できます。

REST APIは、RESTful Webサービスがレスポンスを送信する前にリクエストを認証するため、セキュリティも確保されます。ユーザーの本人確認には、HTTP認証（BasicとBearer Tokenの両方）、APIキー、OAuthを使用してログインアクセスを認証します。

REST APIには、ほかにも次のようなメリットがあります。

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

REST APIとGraphQLの比較

クライアントアプリケーションとサーバーアプリケーションを接続するアーキテクチャとしては、依然としてRESTが最も広く利用されていますが、GraphQL（2012年にFacebookが開発し、2015年にオープンソース化）は、RESTに代わる選択肢として設計されました。GraphQL APIでは、必要なすべてのデータを標準化された形式で1回のリクエストによって取得できるため、REST APIよりも効率的です。一方で、RESTの方が優れている領域もあります。GraphQLの習得には多くの労力が必要であり、RESTと比べてキャッシュがはるかに困難です。また、アプリケーションはリソースを中心に構成されることが多く、GraphQLのようなクエリ言語を必要としない場合もあります。どちらのモデルにも長所と短所があるため、組織は両方を併用することもできます。

NGINXはどのように役立つのか

REST APIの柔軟性は確かに利点です。しかし、柔軟性が高すぎると、動作が遅い、または正常に機能しないAPIを設計してしまう可能性もあります。そのため、多くの開発者は、OpenAPI Specificationを使用してAPIを公開、管理し、ドキュメントを生成しています。

API Connectivity Managerは、F5 NGINX Management Suiteの一部であり、REST API向けのOpenAPI Specificationをサポートしています。API Connectivity Managerは、API開発者のエクスペリエンスを中核に据えて設計されています。軽量なクラウドネイティブのAPI管理ソリューションで、デベロッパーポータルやAPIゲートウェイへのAPI公開をシームレスに統合できます。

NGINX Management Suiteの30日間無料トライアルを開始して、API Connectivity ManagerとInstance Managerをお試しください。