現在、Apigee と Apigee ハイブリッドのドキュメントを表示しています。
Apigee Edge のドキュメントを表示する。
ProxyEndpoint 構成は、クライアント アプリが Apigee を介して 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 の情報のまとまりではなく、プロキシ単位でレポートされます。
- トラブルシューティングと問題解決を迅速に行えます。