クラウドネイティブアプリケーションのデザインパターン

第7章. APIの管理と消費パターン

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

クラウド・ネイティブ・アプリケーションを構築する場合、本書で取り上げている様々なデザイン・パターンを使ってビジネス機能を構築することができる。ビジネス機能をマイクロサービスのコンシューマとして実装したら、API管理パターンを使って、それらのサービスをマネージドAPIとして外部または内部のコンシューマに提示する必要がある。

この章では、API管理で最もよく使われるパターンのいくつかを探る。また、管理されたAPIの上にウェブ、モバイル、デスクトップアプリケーションのようなフロントエンドアプリケーションを構築する際に不可欠な、API消費パターンもいくつか取り上げる。API管理パターンから話を始めよう。

API管理パターン

クラウド（ ）のネイティブ・アプリケーションは、社外のコンシューマ（顧客、パートナーなど）だけでなく、社内のコンシューマ（同じ組織内の他のチームや部署）にも公開されるビジネス機能のセットを持たなければならない。これらのビジネス機能は、APIを通じてコンシューマに公開される。API管理は、既存のマイクロサービス上にAPIを作成、管理、保護、分析、拡張するプロセスである。

API管理によって、クラウド・ネイティブ・アプリケーションのコンシューマは以下のことができるようになる：

• 公開するAPIとのエンゲージメントを高める

• アプリケーションを他のサービスと統合し、新しい機能を構築する。

• APIの利用を収益化する

• ビジネス分析と洞察を生み出す

• 管理され、安全で、レジリエンスに優れたビジネス機能を公開する。

API管理パターンに飛び込む前に、まずAPI管理に関連するいくつかの重要な概念を理解しよう。

APIまたはAPIプロキシは、管理された方法でコンシューマに公開されるクラウドネイティブアプリケーションのビジネス機能を表す。APIは1つ以上のバックエンドマイクロサービスによってバックされ、通常は別のAPIゲートウェイ ランタイムでホストされる。APIはセキュリティ、スロットリング、バージョン管理などの機能のみを提供する。APIレイヤーにビジネスロジックを置くことは避けるべきである。特定のAPIは、複数のバックエンドマイクロサービスを提供することができる（例えば、注文APIは、<host>:<port>/order/managementサービスでホストされる注文管理機能と、異なるコンテキスト（order/status）でホストされる注文ステータス機能によってバックされることができる）。しかし、APIレイヤーでサービスオーケストレーションのようなコンポジションを作成することは推奨しない。APIは通常、REST/OpenAPIまたはGraphQL を介して公開される。

API製品は、API開発者 ポータルを介して開発者にAPIを提示する際に時折使われる概念である。APIプロダクトは1つ以上のAPIを持ち、通常は高レベルのビジネス機能にマッピングされる。例えば、クラウドストレージサービスでは、Storage ServicesがAPIプロダクトとなり、その下にFile API、Blobs API、Disk APIといった複数のAPIを持つことができる。

以下のセクションでは、クラウド・ネイティブ・アプリケーションのAPI管理でよく使われるパターンを探っていく。API ...