ProxyEndpoint 構成は、クライアント アプリが Apigee Edge を経由して API を使用する方法を定義します。ProxyEndpoint は、API プロキシの URL とプロキシの動作を定義します。具体的には、どのポリシーを適用するか、どのターゲット エンドポイントをルーティングするか、これらのポリシーやルートルールを実行するためにどのような条件を満たさなければならないか、といった項目を定義します。
つまり、ProxyEndpoint 構成は、API の実装に必要となるあらゆる作業を定義します。
アンチパターン
1 つの API プロキシに、1 つまたは複数のプロキシ エンドポイントを含めることができます。複数の ProxyEndpoints を定義することは、1 つのプロキシ内に複数の API を実装するための簡単で単純なメカニズムです。この仕組みにより、TargetEndpoint を呼び出す前または後で、ポリシーやビジネス ロジックを再利用できます。
しかし、1 つの API プロキシ内で複数の ProxyEndpoint を定義することで、概念的には、互いに関連性のない多数の API が 1 つのアーティファクト内で組み合わされてしまいます。この結果、各 API プロキシを読んで理解し、デバッグし、管理することが困難になります。これでは、デベロッパーが API を簡単に作成し、管理できるようにするという、API プロキシの基本原理が損なわれてしまいます。
影響
1 つの API プロキシに複数の ProxyEndpoint を定義すると、次のような結果を招く可能性があります。
- デベロッパーが API プロキシを理解し、管理することが難しくなります。
- 分析結果が難読化します。デフォルトでは、分析データはプロキシレベルで集計されます。カスタム レポートを作成しない限り、プロキシ エンドポイントごとの統計情報の指標の明細は出力されません。
- API プロキシの問題のトラブルシューティングが困難になります。
ベスト プラクティス
新しい API プロキシを実装する場合、または既存の API プロキシを再設計する場合は、以下のベスト プラクティスを実施します。
- 1 つの API プロキシを 1 つの ProxyEndpoint で実装します。
- 同じターゲット サーバーを共有する複数の API が存在する場合、あるいはターゲット サーバーを呼び出す前または後に同一のロジックを必要とする複数の API が存在する場合は、共有フローを使用して、このようなロジックを別々の API プロキシに実装する手法を検討してください。
- 同じ開始ベースパスを共有する、接尾辞が互いに異なる複数の API がある場合は、1 つの ProxyEndpoint 内で条件フローを使用します。
- 複数の ProxyEndpoint を持つ 1 つの API プロキシがあり、何の問題もない場合は、どのような措置を取る必要もありません。
1 つの API プロキシにつき 1 つの ProxyEndpoint を使用することで、以下を実現できます。
- プロキシの管理が単純で容易になります。
- プロキシのパフォーマンスやターゲットの応答時間など、アナリティクス内のより有意義な情報が、全 ProxyEndpoint の情報のまとまりではなく、プロキシ単位でレポートされます。
- トラブルシューティングと問題解決を迅速に行えます。