アーキテクチャーまたはシステム設計のコンテキストでは、API 管理は一般的に、クライアント (外部、内部、またはその他) から API、エンドポイント、またはメソッドへのアクセスを管理するために使用される、構成可能で高機能なリバース プロキシーを指します。 API 管理は RESTful API で一般的に使用されますが、これに限定されるものではありません。リクエスト管理と保護のレイヤーを提供して、受信リクエストを検証、検査、変更、および処理できるようにし、バックエンド システムから返されるレスポンスをさらに変更または処理できるようにします。 組織によっては、同様の目標を達成するためにエンタープライズ サービス バス (ESB) を使用する場合があります。 エンタープライズ サービス バスは、そのコンポーネントに関連する追加の影響を含むが、API 管理サービスに対する同じ一連の推奨事項からメリットを得られるテクノロジーのクラスを柔軟に定義した用語です。
API 管理システムやテクノロジーの例としては、以下のようなものがあります:
API 管理パターンは、ArcGIS Enterprise、ArcGIS Online、または ArcGIS Location Platform のサービス エンドポイントへのプロキシーを提供するために使用できますが、これには複雑さが伴うことがあります。 ArcGIS Online や ArcGIS Enterprise 内のクライアント (構成可能な Web アプリケーションや ArcGIS Data Pipelines など) は、適切に定義されていれば API 管理サービスに接続し、その接続を通じて統合できます。 ArcGIS Pro は API 管理を通じてプロキシーされたレイヤーに接続できますが、このパターンは技術的に複雑な要素を伴う可能性があるため、慎重なテストが必要です。
| 機能 | ArcGIS Online | ArcGIS Enterprise | ArcGIS Location Platform | ArcGIS Pro |
|---|---|---|---|---|
| API 管理 |
フルサポート 一部サポート
API 管理の動作は、通常は HTTP トラフィックのパターン全体をバックエンド サーバーに転送する従来のリバース プロキシーとは異なります。 例:
<external-host>:443/server/rest/services/* » <internal-host>>:6443/arcgis/rest/services/*
多くの場合、API 管理には、個々の API URI パスと HTTP メソッド (/routes/extract への POST と /routes/<routeid> への PATCH など) の選択が伴います。そのため、個々のメソッドまたはパターンを定義する必要があるだけでなく、各パターンに異なるルール、動作、バックエンド リスナーまたはサービスを設定できます。 既存の Web サービスのセットが存在しない新しい API やシステムの構築や、異なるバックエンド コンポーネントやシステムが個別の API リクエストの処理を担当するマイクロサービス スタイルのアーキテクチャーを実現する場合によく使用されます。 場合によっては、API 管理で、OpenAPI 仕様などのバックエンド API 定義を使用して、多くのフロントエンド エンドポイントまたはメソッドを作成することがあります。
API 管理には通常、リクエストの内容の操作 (パスの調整または書き換え、ヘッダーの追加または変更、POST 本文の内容に基づく宛先の変更など)、リクエストへのフィルタリングの適用 (レート制限、特定の IP 範囲のブロック、API キーの要求など)、またはレスポンスの操作 (サーバー名の難読化、レスポンス ヘッダーの削除、フィンガープリントまたは識別子の追加など) のいずれかを行う、他の一連の処理オプションも含まれています。 これらの操作は API 管理レイヤーで定義され、リクエストが送信されるたびに機能して、レスポンスが作成されます。
これらのパターンはすべて、通常、エンタープライズ サービス バス テクノロジーにも当てはまりますが、いくつかの違いがあります。 ESB は同期メッセージの配信に重点を置く傾向があり、システムの一部の変更 (新しいレコードの追加、更新の実行など) によってこの変更が ESB にプッシュされた後、ESB がメッセージを変換して他のシステムにプッシュし、メッセージの同期を維持します。 ある意味では、API 管理はクエリーとポーリングの方法論であり、ESB では強力なメッセージ配信コミットメント、パブリッシュ-サブスクライブ パターン、またはその他の同様のアプローチが導入されることがよくあります。
API 管理は、ArcGIS を用いたさまざまなパターンで使用できます。 一般に、マップ、フィーチャ、ジオプロセシング サービスなどの ArcGIS Server ベースのサービスの前面にデプロイされるユース ケースや、これらのサービスを別のエンタープライズ システム、またはカスタマイズされたアプリケーションを使用する開発者やエンド クライアントに公開する必要があるシナリオに API 管理は最も適しています。
API 管理の実施に関するいくつかの重要な考慮事項は次のとおりです。
API 管理は一般的に、スタンドアロンの ArcGIS Server デプロイメントのアーキテクチャー パターンとして最適に機能します。 ArcGIS Enterprise デプロイメントの一部としてフェデレーション サーバーに必要なトークン交換と検証の処理ははるかに複雑であり、さまざまな認証リクエストとエンドポイントを処理するために、高度な ArcGIS 構成または API 管理構成および知識が必要になります。
API 管理システムを通じてアクセスされる ArcGIS REST サービスは、通常、匿名でアクセスでき、ネットワークまたはファイアウォール レベルで保護されています。API 管理サービスからのリクエストは、さらなる認証手順を経ることなく ArcGIS バックエンドに送信されます。 ArcGIS では、組み込みのユーザー名とパスワードから SAML や OIDC まで、多くの認証パターンをサポートしていますが、API 管理パターンでは多くの場合、API 管理サービスから発信されたリクエストにバックエンド API が匿名でアクセスできることを前提としています。
API 管理は一般的に、ArcGIS Server サイト全体ではなく、特定のサービスまたはエンドポイントを公開する目的で使用する必要があります。 サイト全体を公開することが目標である場合、通常であれば、より幅広いワークフローとの互換性が高い従来のリバース プロキシーがより優れたソリューションとなります。
ArcGIS では全般的に詳細な REST API を提供しているため、API 管理サービスでは柔軟なワイルドカード パターンをサポートするか、特定のパスのみを転送する必要があります。 これは、サービスを ArcGIS クライアント ソフトウェアに公開することが目標である場合に特に重要となります。ArcGIS クライアント ソフトウェアは、完全に利用可能な 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 管理サービスのレベルでのみ認証を適用し、すべてのユーザー アクティビティーでそのエンドポイントを使用するようにすることが目的である場合、バックエンドとして定義された ArcGIS サービスは、通常、セキュリティーで保護されないか、すべての人と共有されるようにして、ネットワーク設計またはファイアウォールを介してパブリック アクセスまたは組織のアクセスが制限され、API 管理サービスからのみアクセスが有効になるように構成する必要があります。
Web コンテキスト URL とプロキシー関連ヘッダーの実装を検討して、API 管理の背後にある ArcGIS Server コンポーネントがプロキシーを認識し、可能な場合は有効な URL を返すようにします。
API 管理サービスを介してリクエストから返されるリンクは、検査して、後続のリクエストに適切なホスト名とコンテキストを使用するように修正する必要があります。 API 管理サービスは、ArcGIS が返す URL など、レスポンス本文の内容を置き換える機能を備えていることが多く、これはバックエンドのレスポンスを上書きするのに有用です。 たとえば、非同期印刷サービス リクエストは、結果の PDF 出力に最終的な URL を返し、ユーザーがそれをリクエストします。この URL は内部ホスト名を参照している場合があり、コンテンツを API 管理システムで書き換えることができます。
API 管理パターンが適用されているエンドポイント (ジオコーディングやルーティング エンドポイントなど) は、標準的な ArcGIS インターフェイスへの統合がより複雑になる場合があります。 たとえば、Azure API Management を介して提供される、サブスクリプション キーが必要なジオコーディング サービスは、ArcGIS Online 組織向けに構成された標準的なジオコーディング サービスとして完璧に機能しないことがあります。 詳細については、次のセクションをご参照ください。
API 管理サービスを操作したり、クライアント エラーをトラブルシューティングする際は、クライアントから API 管理を通じて送信されたリクエストと、バックエンド サービスに直接送られたリクエストを比較し、HTTP ヘッダーや URL を注意深く確認して、関連する相違点を特定してください。
定義上、API 管理には認証レイヤーは含まれませんが、多くの組織では、ユーザーの検証と承認管理の目的で、API 管理エンドポイントに認証を適用したいと考えます。 一般的な API 管理認証方法には、API またはサブスクリプション キーの使用、および既存の ID プロバイダー (IdP) に対する OAuth ベースの認証方法との統合が含まれます。 これらの各パターンは、ArcGIS 統合ワークフローでいくつかの課題を引き起こす可能性があります。
API 管理ベースのクライアント認証方法は、標準の ArcGIS クライアントと互換性がない場合があることに注意してください。 たとえば、サービス固有のヘッダーまたは Bearer authorization ヘッダーを使用したヘッダーベースの認証が API 管理システムで必須となっている場合、標準の ArcGIS クライアントは、そのサービスへのアクセスをサポートするリクエストにそのヘッダーを動的に追加できません。 同様に、API キーは API 管理インターフェイスを介して追加される共通認証レイヤーである可能性がありますが、アプリケーション開発者はこの要件を認識し、これらのサービスをアプリケーションに統合するためにリクエストに追加できる必要があります。 さまざまな ArcGIS SDK とサービス登録パターンで、この種のサブスクリプション キーまたは API キー認証パターンをサポートできますが、認証パターンが適切であると見なす前に、慎重にテストする必要があります。
API 管理に対する OAuth ベースの認証には、他の課題もあります。 サポートされている SDK を使用してカスタム アプリケーションを開発する場合、OAuth サービスへの初期リダイレクトを提供して、トークンまたはコードを返し、そのトークンを使用してそのセッションの後続のリクエストにアペンドするのは比較的簡単なことかもしれません。 ただし、既製の ArcGIS アプリケーションを使用する場合、これらのクライアントは ArcGIS によって管理されていない追加の認証手順なしで ArcGIS ジオサービスに直接アクセスすることを想定しているため、この構成を正常に使用することははるかに困難です。
一般に、API キーまたはサブスクリプションキーを使用すると、このコンテキストで最も成功する統合パスが提供されますが、次の推奨事項があります。
API キーまたはサブスクリプション キーでは、URL クエリー パラメーターとしての使用がサポートされている必要があります。 ヘッダーベースの認証は、カスタム Esri Maps SDK ベースのアプリケーションや Python ベースの統合などの一部のワークフローでサポートできますが、ほとんどの既存のインターフェイスでは、現時点で ArcGIS 以外の認証ヘッダーを使用することはできません。
API キーは、最新バージョンの ArcGIS Online または ArcGIS Enterprise で作成されたコンテンツ アイテムに、アイテムの作成時に指定されるカスタム パラメーターとして追加することも、アイテムに登録されている URL に直接アペンドすることもできます。 これらのオプションを注意深くテストして、リクエストされたコンテンツへの十分なアクセスを提供するかどうかを評価します。
ArcGIS Pro で API キーで保護されたサービスを使用する場合、パスからのデータの追加ワークフローでは、カスタム パラメーターの使用もサポートされます。