API Connect のパッケージ化戦略および用語

このパッケージ化戦略は、API プロバイダーが API コンシューマーの要件を満たせるようサポートするものです。 IBM® API Connect を使用して API を開発およびデプロイする前に、パッケージ化戦略の背後にある概念および用語を理解する必要があります。

API

アプリケーション・プログラミング・インターフェース (API) は、業界標準のソフトウェア・テクノロジーの 1 つです。API は、ソフトウェア・アプリケーションを構築するためのルーチン、プロトコル、およびツールのセットです。API は、ソフトウェア・コンポーネント間の相互作用の方法を指定し、共通の資産とプロセスに素早くアクセスできるようにします。API は公開できます (GitHub 上での提供など)。また、クライアント資格情報を要求したり、アプリケーション内で非公開のままにしたりできます。したがって、API はその使用法に応じて、外部 (公開)、パートナー (保護)、内部 (非公開) に分類できます。

API をバージョン管理して、複数の製品にパッケージ化し、開発者ポータル上で API コンシューマーに配布できます。API の作成および管理については、API およびアプリケーションの開発およびAPI の管理を参照してください。

プランと製品

プランと製品は、API Connect 独自のパッケージ化構成体です。API プロバイダーは製品を使用して、API を使用するアプリケーション開発者 (API コンシューマー) に 1 つ以上の API を提供できます。一方、プロバイダーはプランを使用して、API に対するアクセスを制御するとともに、API 使用量を管理します。 製品とは、API とそれに付随するプランの両方が含まれるパッケージのことです。API Designer での製品の操作を参照してください。

アプリケーション開発者が API を使用できるようにするには、1 つ以上のプランに API を組み込み、さらにそのプランを 1 つ以上の製品に組み込む必要があります。

プランには、以下の機能があります。

• プランにより、アプリケーション開発者に対して使用可能にする API を制御します。
• プランにより、1 つ以上の API からの操作の集合が使用可能になります。
• プランでレート制限を API に適用することで、オファリングを差別化します。
• プランでさまざまなレート制限を実装して、API を使用するアプリケーションが、指定した時間間隔内に実行を許可される要求の数を指定します。

レート制限は、あるプランのすべての操作で共有されるデフォルトのレートとして実装するか、API の特定の操作に対して設定できます。プランでは、API コンシューマーにさまざまなレベルのサービスを提供するために、異なるレート制限を使用できます。例えば、「デモ・プラン」は毎分 10 個の呼び出しのレート制限を適用し、「フルプラン」は毎秒 1000 個の呼び出しまで許可することができます。

以下の図に、プランを使用して、1 つ以上の API の操作を使用可能にし、プランと個々の操作の両方にレート制限を設定する仕組みを示します。

製品を使用して、その製品に含まれる API のライフサイクルを管理します。製品ライフサイクルの状態には、ドラフト、ステージング済み、公開済み、非推奨、廃棄済み、アーカイブ済みがあります。ドラフト状態の製品は、カタログ に保存された時点で、ステージング状態に移行します。そのカタログが公開されると、製品は公開済みの状態に移行します。製品が公開済みの状態になり、API Connect 開発者ポータルに表示されると、API コンシューマーがその製品に含まれる API にアクセス可能になります。製品が公開された後、アプリケーション開発者は、その製品に含まれる 1 つ以上のプランにアプリケーションを登録することで、その製品に含まれる API にアクセスできるようになります。

以下の図に、製品、プラン、および API の階層を示します。

プランと製品について詳しくは、API Manager での製品の操作を参照してください。

カタログとスペース

カタログには、製品の集合が含まれます。カタログはステージング・ターゲットであり、カタログを介して製品は (付随するプランおよび API と共に) 開発者ポータルに公開されます。製品と API を開発者ポータルで公開する前に、カタログを使用して、製品と API をテストのために分離します。標準的なワークフローでは、API プロバイダーは、API を開発およびテストする際には開発カタログを使用し、外部で使用できる状態の API を公開する際には実稼働カタログを使用します。各カタログには、公開済み製品を公開するための開発者ポータルが関連付けられています。カタログには、そのカタログ内の API に対する API 要求を処理するゲートウェイ・サービスが関連付けられ、そのサービスを介してランタイム機能が組み込まれます。

API Connect にはシンジケーション機能が組み込まれています。これにより、API プロバイダーはカタログを API の開発目的に応じて複数のステージング・ターゲット (またはスペース) にパーティション化できます。API プロバイダーの各開発チームは、専用のスペースを使用して、他のチームとは独立して製品を管理できます。スペースには、そのスペースで作成および公開された製品と API のみに関連する独自の機能セットが備えられています。 特定のカタログ内のスペースの製品と API は、同じ開発者ポータルに公開されます。 スペースは、開発者ポータルには表示されません。開発者ポータル上の API を使用するアプリケーション開発者は、API 開発者によって使用されるスペース構成を意識することはありません。開発者ポータルでは、API はカタログ内で調整されたオファリングとして表示されます。

カタログとスペースについて詳しくは、カタログの処理およびシンジケーションを使用してカタログをスペーススペースにパーティション化するを参照してください。

組織とユーザー

API Connectのコンテキストでは、組織のタイプには、プロバイダーと開発者の 2 つがあります。プロジェクト・チーム、部署、または部門を組織にすることができます。

プロバイダー組織と開発者組織の責任は、API Connect のロール に対応します。一部のロールは組織から独立しています。その一例は、クラウド・インフラストラクチャーを管理してシステムを稼働中の状態に維持する管理者です。定義済みのすべてのロールとアクセス権については、API Connect のユーザー・ロールを参照してください。

API Connect エコシステムでは、ユーザーは組織から独立した存在です。ユーザーは、複数のプロバイダー組織または開発者組織のメンバーになることができます。

企業の基幹業務ごとに API 開発環境を提供するために、1 つの API Connect クラウドに複数のプロバイダー組織を作成できます。API Connect クラウドは、API Connect インストール済み環境の構成要素であるサーバーの集合です。これには、サーバー内にある構成情報およびメタデータも含まれます。クラウド・インフラストラクチャーは、すべての組織で共有され、(クラウドまたはシステム管理者により) 組織とは独立して管理されます。 以下の図は、プロバイダー組織、開発者組織、およびユーザーの間の関係を示しています。この図に示されているクラスターは、同じ機能を持つ複数のサーバーからなる論理グループです。

組織について詳しくは、プロバイダー組織の管理および開発者組織の管理を参照してください。

アプリケーション

プロバイダー組織は、API だけでなく、Node.js と Java テクノロジーを使用して (API を関連付けた) アプリケーションを作成することもできます。これらの API とアプリケーションは、公開されると開発者アプリケーションによって呼び出されます。開発者アプリケーションには、サービス、システム、またはコンテンツとやり取りするために API にアクセスするクライアント・コードが含まれています。通常、開発者アプリケーションは、HTTP プロトコルを使用するモバイル・アプリケーションまたは Web アプリケーションです。

プロバイダー・アプリケーションの作成については、API とアプリケーションの開発を参照してください。

2 つのカタログを使用するプロバイダー組織の例

以下の図に、プロバイダー組織と開発者組織における API、プラン、製品、カタログ、およびスペースの使用例を示します。この例では、プロバイダー組織で 2 つのカタログが作成され、さまざまな要件に対応するステージング・ターゲットとして機能しています。

• カタログ 1 では、プロバイダーの個々の開発チームで使用する製品を分離する必要がないため、スペースが有効にされていません。このカタログに対するアクセス権を持つ API 開発者は、ドラフト API を作成し、それらを製品としてステージングしてカタログに公開します。公開された製品および API を探索、ディスカバー、使用する権限は、複数の開発者組織に付与されます。各開発者組織では、カタログ 1 で公開された製品と API が単一の開発者ポータルで公開されます。
• カタログ 2 は 2 つのスペース (X および Y) にパーティション化されているため、プロバイダーの 2 つの開発者チームがそれぞれの製品を独立して管理できます。これらのチームはそれぞれに個別のスペースに API を (製品として) ステージングして公開し、複数の開発者組織のアプリケーション開発者に対して API へのアクセスを可能にします。各開発者組織では、両方のスペースから公開された製品と API が同じ開発者ポータルで公開されます。このポータルにアクセスするアプリケーション開発者には、両方のスペース内の API が調整されたオファリングとして表示されます。