反模式：在 API 代理中定义多个 ProxyEndpoint

您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。 信息

ProxyEndpoint 配置定义了客户端应用通过 Apigee Edge 使用 API 的方式。 ProxyEndpoint 定义了 API 代理的网址以及代理的行为方式：要应用哪些政策、要路由到的目标端点，以及要执行的这些政策或路由规则必须满足的条件。

简而言之，ProxyEndpoint 配置定义了实现 API 所需的所有操作。

反模式

API 代理可以有一个或多个代理端点。定义多个 ProxyEndpoint 是一种在单个代理中实现多个 API 的轻松且简单的机制。这样，您就可以在调用 TargetEndpoint 之前和之后重复使用政策和/或业务逻辑。

另一方面，在单个 API 代理中定义多个 ProxyEndpoint 时，最终会将多个不相关的 API 合并为一个工件。这使得 API 代理更难以读取、理解、调试和维护。这将违反 API 代理的主要理念：开发者可以轻松创建和维护 API。

影响

API 代理中的多个 ProxyEndpoint 可以：

  • 使开发者难以理解和维护 API 代理。
  • 混淆分析。默认情况下，会在代理级别汇总分析数据。除非您创建自定义报告，否则系统不会按代理端点对指标进行细分。
  • 使得难以排查 API 代理问题。

最佳实践

在实现新 API 代理或重新设计现有 API 代理时，请使用以下最佳做法：

  1. 使用一个 ProxyEndpoint 实现一个 API 代理。
  2. 如果有多个 API 共享公共目标服务器和/或要求目标服务器在调用前或调用后使用相同的逻辑，请考虑使用共享流在不同的 API 代理中实现此类逻辑。
  3. 如果有多个 API 共享公共起始基本路径，但后缀不同，则在单个 ProxyEndpoint 中使用条件流。
  4. 如果存在具有多个 ProxyEndpoint 的 API 代理，并且该代理未出现任何问题，则无需执行任何操作。

在每个 API 代理中使用一个 ProxyEndpoint 会导致：

  1. 更简单、更易于维护代理
  2. Analytics（分析）中的更佳信息（例如代理性能和目标响应时间）会单独报告，而不是对所有 ProxyEndpoint 汇总。
  3. 更快排查问题和解决问题

深入阅读