REST APIは、REpresentational State Transfer（REST）モデルに従うアプリケーション プログラミング インターフェイス（API）の一種です。インターネットなどのネットワークを介して2つのシステム（クライアントとサーバ）間でデータ表現と通信を行うためのモデルです。REST APIは、社内アプリケーションとサードパーティ アプリケーション間での情報交換をサポートし、企業が複数のエンドポイントを自社のアプリケーション エコシステムに統合できるようにします。
注：厳密に言うと、RESTはモデルのことを指しており、そのモデルに従うAPIを示す形容詞ではありません。正確な用語はRESTful APIです。ただし、REST APIの方が一般的に使用されているため、この記事ではREST APIを使用します。
RESTはREpresentational State Transferの略で、2000年にコンピュータ サイエンティストのRoy Fielding氏によって作られたアーキテクチャ スタイルです。RESTによって開発者に柔軟性がもたらされるため、マイクロサービス アーキテクチャでアプリケーションを接続するのに理想的です。
RESTでは、アプリケーションとAPIがRESTfulであると見なされるために従う必要のある6つの制約条件が定義されています。
これらの制約条件の詳細については、Wikipediaを参照してください。
インターフェイスを統一すると、全体的なシステム アーキテクチャが簡素化され、やり取りの可視性が向上します。また、情報が標準的な形式で転送されることを保証する特定の要件もあります。
以下の4つの制約条件によって、RESTインターフェイスを統一することができます。
クライアント/サーバ アーキテクチャは、クライアント、サーバ、リソースで構成されます。ユーザー インターフェイス（クライアントによって制御）をデータ ストレージ（サーバによって制御）から分離することは、クライアント コンポーネントとサーバ コンポーネントが自律的に発展できることを意味します。また、複数のプラットフォーム間のクライアント ユーザー インターフェイスの移植とサーバの拡張が簡素化されます。
インターネット上のクライアント/サーバのやり取りは、HTTPを介して行われます。
クライアント/サーバ通信におけるステートレス性とは、サーバがクライアントまたはクライアントと確立されたセッションに関する情報を一切保存しないことを意味します。各メッセージ内のセッション関連情報に対するクライアントの表現は、以前のメッセージからのコンテキストがなくても単独でサーバが理解できる必要があります。これによってサーバの負荷が軽減され、大容量アプリケーションのパフォーマンスが向上します。
クライアントは、サーバに直接接続しているのか、リバース プロキシやロード バランサなどの仲介デバイスに接続しているのかを知る必要がありません（通常は区別できません）。仲介デバイスは拡張性の向上を支援し、セキュリティを管理して、サーバがビジネス ロジックだけを担うことができるようにします。
HTTPクライアントと仲介デバイスは、サーバのレスポンスをキャッシュしてサーバの負荷を軽減し、エンド ユーザーへのデータ配信速度を向上させることができます。サーバは、レスポンスがキャッシュ可能かどうかを示す必要があります。キャッシュ不可能な場合は、後続のエンドユーザーのリクエストに対するレスポンスが正しく最新である（「古くなっている」可能性がない）ことが保証されます。クライアントは一意の識別子であるURLによってリソースにアクセスするため、クライアントはリソース レベルで何をキャッシュすべきかを判断できます。
オンデマンドのコードとは、サーバがクライアントの機能を一時的に拡張またはカスタマイズするために実行可能コードを送信できることを意味します。これによって、クライアントはその機能を実装する必要がなくなります。オンデマンドのコードは、オプションの制約条件です。
RESTで最も重要なデータ表現または抽象化がリソースです。RESTリソースは、デジタル ドキュメントから非デジタル オブジェクトまで、あらゆる種類の抽象化された情報になります。任意の時点でのリソースの状態をリソース表現と言います。
リソース表現には次の3つの要素があります。
REST APIは、一意のURIでアクセスできる連結されたリソースの集合（リソース モデル）で構成されます。クライアントは、レスポンス内の関連リソースとURIにリンクすることによって柔軟な機能を実現できます。一般に、REST APIへのリクエストはHTTP GETリクエストの形式で送信されます。多くの場合、サーバはレスポンスの形式をJSONに設定します。
以下のHTTPリクエスト メソッドは、示されている方法でリソースを操作するために使用されます。
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がクライアント アプリケーションとサーバ アプリケーションを接続するための最も一般的なアーキテクチャであるのに対して、GraphQL（2012年にFacebookが開発、2015年にオープン ソース化）は、RESTに代わるものとして設計されました。GraphQL APIは、必要なすべてのデータが1つのリクエストで標準化された形式で要求されるため、REST APIよりも効率的ですが、RESTの方が優れている面があります。GraphQLでは多くのことを覚える必要があり、RESTよりもはるかにキャッシュ可能性が低くなります。また、多くの場合で、アプリケーションはリソースによって駆動されるため、GraphQLのようなクエリ言語は必要ありません。とは言え、各モデルにはメリットとデメリットがあるため、組織は両方を使用することもできます。
REST APIの柔軟性がメリットであることは間違いありません。しかし、柔軟性が高すぎると、APIの設計に時間がかかったりAPIが破損したりする可能性もあります。これが、多くの開発者がOpenAPI仕様を使用してAPIのドキュメントを公開、管理、生成することを選ぶ理由です。
F5 NGINX Management Suiteの一部であるAPI Connectivity Managerは、REST API向けのOpenAPI仕様をサポートしています。API Connectivity Managerは、API開発者のエクスペリエンスを軸にして設計されました。APIを開発者ポータルやAPIゲートウェイに公開するためにシームレスに統合できる、軽量でクラウドネイティブのAPI管理ソリューションです。
API Connectivity ManagerとInstance Managerが付属した、NGINX Management Suiteの30日間無料のトライアル版をお試しください。