アーキテクチャーまたはシステム設計のコンテキストでは、API 管理は一般的に、クライアント (外部、内部、またはその他) から API、エンドポイント、またはメソッドへのアクセスを管理するために使用される、構成可能で高機能なリバース プロキシーを指します。 API 管理は RESTful API で一般的に使用されますが、これに限定されるものではありません。リクエスト管理と保護のレイヤーを提供して、受信リクエストを検証、検査、変更、および処理できるようにし、バックエンド システムから返されるレスポンスをさらに変更または処理できるようにします。 組織によっては、同様の目標を達成するために_エンタープライズ サービス バス_を使用する場合があります。 エンタープライズ サービス バスは、そのコンポーネントに関連する追加の影響を含むが、API 管理サービスに対する同じ一連の推奨事項からメリットを得られるテクノロジーのクラスを柔軟に定義した用語です。
API 管理システムの例としては次のようなものがあります。
API 管理の動作は、通常は HTTP トラフィックのパターン全体をバックエンド サーバーに転送する従来のリバース プロキシーとは異なります。 例:
<external-host>:443/server/rest/services/* » <internal-host>>:6443/arcgis/rest/services/*
多くの場合、API 管理には、個々の API URI パスと HTTP メソッド (つまり、/routes/extract への POST と /routes/<ルート ID> への PATCH) の選択が伴います。そのため、個々のメソッドまたはパターンを定義する必要があるだけでなく、各パターンに異なるルール、動作、バックエンド リスナーまたはサービスを設定できます。 既存の Web サービスのセットが存在しない新しい API やシステムの構築や、異なるバックエンド コンポーネントやシステムが個別の API リクエストの処理を担当するマイクロサービス スタイルのアーキテクチャーを実現する場合によく使用されます。 場合によっては、API 管理で、OpenAPI 仕様などのバックエンド API 定義を使用して、多くのフロントエンド エンドポイントまたはメソッドを作成することがあります。
API 管理には通常、リクエストの内容の操作 (パスの調整または書き換え、ヘッダーの追加または変更、POST 本文の内容に基づく宛先の変更)、リクエストへのフィルタリングの適用 (レート制限、特定の IP 範囲のブロック、API キーの要求)、またはレスポンスの操作 (サーバー名の難読化、レスポンス ヘッダーの削除、フィンガープリントまたは識別子の追加) のいずれかを行う、他の一連の処理オプションも含まれています。 これらの操作は API 管理レイヤーで定義され、リクエストが送信されるたびに機能して、レスポンスが作成されます。
これらのパターンはすべて、通常、エンタープライズ サービス バス テクノロジーにも当てはまりますが、いくつかの違いがあります。 ESB は同期メッセージの配信に重点を置く傾向があり、システムの一部の変更 (新しいレコードの追加、更新の実行) によってこの変更が ESB にプッシュされた後、ESB がメッセージを変換して他のシステムにプッシュし、メッセージの同期を維持します。 ある意味では、API 管理はクエリーとポーリングの方法論であり、ESB では強力なメッセージ配信コミットメント、パブリッシュ/サブスクライブ パターン、またはその他の同様のアプローチが導入されることがよくあります。
API 管理は、ArcGIS を用いたさまざまなパターンで使用できます。 一般に、マップ、フィーチャ、ジオプロセシング サービスなどの ArcGIS Server ベースのサービスの「前面」にデプロイされるユース ケースや、これらのサービスを別のエンタープライズ システム、またはカスタマイズされたアプリケーションを使用する開発者やエンド クライアントに公開する必要があるシナリオに API 管理は_最も適しています_。 API 管理の実施に関するいくつかの重要な考慮事項は次のとおりです。
例:
/arcgis/rest/services/ServiceName/MapServer/arcgis/rest/services/ServiceName/MapServer/exportImage/arcgis/rest/services/ServiceName/MapServer/0/query/arcgis/rest/services/ServiceName/MapServer/1/queryAPI 管理は、エンタープライズ システム間の統合オプションを提供する方法として、ますます普及しています。 多くの組織が、API 管理システムによってすべての内部トランザクションが仲介されるようにするためのポリシーに投資したり、ポリシーを作成しています。また、場合によっては、外部からアクセス可能なサービスを作成するために API 管理の使用を必要とします。 システム統合に関連するベスト プラクティスには次のようなものがあります。
API 管理には定義上、認証レイヤーは含まれませんが、多くの組織では、ユーザーの検証と承認管理の目的で、API 管理エンドポイントに認証を適用したいと考えます。 一般的な API 管理認証方法には、API またはサブスクリプション キーの使用、および既存の ID プロバイダー (IdP) に対する OAuth ベースの認証方法との統合が含まれます。 これらの各パターンは、ArcGIS 統合ワークフローでいくつかの課題を引き起こす可能性があります。
API 管理ベースのクライアント認証方法は、標準の ArcGIS クライアントと互換性がない場合があることに注意してください。 たとえば、サービス固有のヘッダーまたはBearer 認証ヘッダーを使用したヘッダーベースの認証が API 管理システムで必須となっている場合、標準の ArcGIS クライアントは、そのサービスへのアクセスをサポートするリクエストにそのヘッダーを動的に追加できません。 同様に、API キーは API 管理インターフェイスを介して追加される共通認証レイヤーである可能性がありますが、アプリケーション開発者はこの要件を認識し、これらのサービスをアプリケーションに統合するためにリクエストに追加できる必要があります。 さまざまな ArcGIS SDK とサービス登録パターンで、この種のサブスクリプション キーまたは API キー認証パターンをサポートできますが、認証パターンが適切であると見なす前に、慎重にテストする必要があります。
API 管理に対する OAuth ベースの認証には、他の課題もあります。 サポートされている SDK を使用してカスタム アプリケーションを開発する場合、OAuth サービスへの初期リダイレクトを提供して、トークンまたはコードを返し、そのトークンを使用してそのセッションの後続のリクエストに追加するのは比較的簡単なことかもしれません。 ただし、ArcGIS の既製アプリケーションを使用する場合、これらのクライアントは ArcGIS によって管理されていない追加の認証手順なしで ArcGIS ジオサービスに直接アクセスすることを想定しているため、この構成を正常に使用することははるかに困難です。
一般に、API キーまたはサブスクリプションキーを使用すると、このコンテキストで最も成功する統合パスが提供されますが、次の推奨事項があります。