アンチパターン: API プロキシで複数の ProxyEndpoint を定義する

ProxyEndpoint 構成は、クライアント アプリが Apigee Edge を経由して API を使用する方法を定義します。ProxyEndpoint は、API プロキシの URL とプロキシの動作を定義します。具体的には、どのポリシーを適用するか、どのターゲット エンドポイントをルーティングするか、これらのポリシーやルートルールを実行するためにどのような条件を満たさなければならないか、といった項目を定義します。

つまり、ProxyEndpoint 構成は、API の実装に必要となるあらゆる作業を定義します。

アンチパターン

1 つの API プロキシには、1 つまたは複数のプロキシ エンドポイントを含めることができます。複数の ProxyEndpoints を定義することは、1 つのプロキシ内に複数の API を実装するための簡単で単純なメカニズムです。この仕組みにより、TargetEndpoint を呼び出す前または後で、ポリシーやビジネス ロジックを再利用できます。

しかし、1 つの API プロキシ内で複数の ProxyEndpoints を定義することで、概念的には、互いに関連性のない多数の API が 1 つのアーティファクト内で組み合わされてしまいます。この結果、各 API プロキシを読み取り、理解し、デバッグし、管理することが困難になります。これでは、デベロッパーが API を簡単に作成し、管理できるようにするという、API プロキシの基本原理が損なわれてしまいます。

影響

1 つの API プロキシに複数の ProxyEndpoint を定義すると、次のような結果を招く可能性があります。

  • デベロッパーが API プロキシを理解し、管理することが難しくなります。
  • 分析結果が難読化します。デフォルトでは、分析データはプロキシレベルで集計されます。カスタム レポートを作成しない限り、プロキシ エンドポイントごとの統計情報の明細は出力されません。
  • API プロキシの問題のトラブルシューティングが困難になります。

ベスト プラクティス

新しい API プロキシを実装する場合、または既存の API プロキシを再設計する場合は、以下のベスト プラクティスを実施します。

  1. 1 つの API プロキシを 1 つの ProxyEndpoint で実装します。
  2. 同じターゲット サーバーを共有する複数の API が存在する場合、あるいはターゲット サーバーを呼び出す前または後に同一のロジックを必要とする複数の API が存在する場合は、共有フローを使用して、こうしたロジックをそれぞれの API プロキシに実装する手法を検討します。
  3. 同一の開始ベースパスを共有する複数の API が、接尾辞は互いに異なる場合は、1 つの ProxyEndpoint 内で条件フローを使用します。
  4. 複数の ProxyEndpoints を持つ 1 つの API プロキシがあり、何の問題もない場合は、どのような措置を取る必要もありません。

1 つの API プロキシにつき 1 つの ProxyEndpoint を使用することで、以下を実現できます。

  1. プロキシの管理が単純で容易になります。
  2. プロキシのパフォーマンスやターゲットの応答時間など、アナリティクス内のより有意義な情報が、全 ProxyEndpoint の情報をロールアップするのではなく、プロキシ単位でレポートされます。
  3. トラブルシューティングと問題解決を迅速に行えます。

関連情報