Jason Ehmke指出AI网关无法解决所有API问题，需要API平台来自动化安全与治理。他提出了API平台成功的六大支柱：明确策略标准、API生命周期管理、自动化工具、安全合规、开发者体验以及监控指标。避免高层支持缺失、网关依赖、副总裁例外、手动操作和开发者抵触等陷阱至关重要。
译自：6 Pillars for a Best in Class API Strategy
作者：Loraine Lawson
AI 网关并不能解决开发者所有的 API 问题，Jason Ehmke 在纽约举办的 Kong API Summit 2025 大会上告诉观众。
DevGrid 是一家工程运营平台，可提供对软件团队和技术栈的可见性。该公司首席技术官兼联合创始人 Ehmke 在 10 月 15 日的“打造一流 API 策略”演讲中表示，目前这确实是 API 的狂野西部。
尽管 AI 网关是 API 管理 策略的关键组成部分，但他认为仅靠它们是不够的。
“你不知道谁在使用它，也不知道谁没有，”Ehmke 说。“你强制进行了身份验证，但它是选择加入的，而不是强制的。你设置了速率限制，但你不知道你正在为谁设置速率限制？”
不出所料，这会导致问题。Ehmke 分享了一些相关统计数据：
“大多数人都经历过 API 安全事件，或者因为 API 安全问题而延迟发布——这是真实存在的。你不是一个人在面对这些问题，”他说。“但泄露事件的代价高昂，可能是微不足道的，也可能是巨大的。它们的代价极其高昂。”
为了驯服这个 API 的狂野西部，Ehmke 呼吁 IT 部门投资于 API 平台，该平台可以自动化安全和 治理，而这是 API 网关 无法做到的。
API 的狂野西部
Ehmke 指出，目前许多组织对他们的 API 感到困惑：有多个客户 API——哪个是正确的？该端点是否应该是公开的？为什么客户在 IT 部门之前就发现了 PII 泄露？
他认为，API 网关能提供一些信息，但不够。具体来说，它提供：
- 代理，但不知道谁还没有迁移；
- 身份验证，但它是选择加入而非强制的。
- 速率限制但没有业务上下文；以及
- 指标，但只是请求计数。
但 Ehmke 表示，开发人员还需要知道：
- 谁拥有哪个 API，在凌晨 3 点出现故障时该找谁？
- 哪些 API 可以移除而不会破坏生产环境？
- 如何找到 API 而不是构建重复项，以及
- API 是否符合实际证据。
“是时候构建一个真正进行治理的平台了，”他说。
API 的乌托邦
将狂野西部与他定义的 API 乌托邦进行对比，后者提供：
- API 的完整实时可见性；
- 自动构建的安全。
- 重用 API 设计块，强制执行标准；
- 3 倍的交付速度；
- 合规性，审计员和监管机构会成为你的支持者；以及
- 易于货币化的 API。
Ehmke 说：“通过将其视为不仅仅是一个网关，你可以在单个云中实现完整的可见性、安全性、重用性、交付、合规性和货币化。”“网关是整体安全态势的一部分，但它不够。”
API 平台成功的六大支柱
为了实现这一目标，他建议拥抱 API 平台成功的六大支柱。
“我们可以做得更好。我们可以更快地完成更多工作，”他说。“我们可以减少安全事件，降低开发成本，”他说。“将它视为六个不同的支柱，有助于你理解在 API 平台上应该考虑什么，而不仅仅是一个网关。”
第一支柱是建立明确的策略和标准，其中治理是强制性的。第一支柱意味着要求：
- 使用 OAuth；
- 对所有 API 进行版本控制；
- 全面记录所有 API；以及
- 要求所有 API 通过安全测试。
Ehmke 说：“这些是你需要写入代码、写入法律的东西。”
第二支柱是 API 生命周期管理，从设计、构建、测试、部署、运营到弃用网关。
Ehmke 解释说：“这些是你构建在平台中的自动化和工具。”“一切都应该在你的平台中进行分类，这样你就不会意外地进入生产环境而导致 API 泄露社会安全号码。同样，在没有适当的检查和平衡机制的情况下，这些事情会发生。”
例如，他解释说，要设计一个网关，你应该确保它是 OpenAPI 3.1 有效的，包含安全方案，定义了自动流，目录中有所有者，并进行数据分类。构建网关需要进行向后兼容性检查、语义版本控制、契约测试，以及对其性能和消费者影响的评估。
API 平台应处理：
- 清单和所有权，以便为所有端点提供单一事实来源；
- 契约测试，以便在每次更改时自动运行测试；
- 策略即代码，在 CI/CD 和网关中强制执行规则；
- 渐进式交付，例如通过网关进行金丝雀/影子/回滚；
- 消费者注册表，将调用者映射到版本并执行影响分析；以及
- 可观测性，以便 服务级别目标 (SLO) 预算与部署权限挂钩。
第三支柱需要自动化和工具来处理平台的设计时、运行时和操作。例如，在设计时，应该从规范生成代码、进行模式验证和使用模拟服务器。运行时应包括速率限制和配额；身份验证和转换以及熔断。操作应允许 SLO 自动回滚、证书轮换和合规性报告。
Ehmke 说：“人工成本高昂。他们会休假，所以要自动化你能自动化的一切。”“这是一个很大的问题。这会造成很多安全漏洞。API 团队、功能团队可以完成工作，但他们并不总是考虑安全和合规性的整体大局。”
第四支柱涵盖安全和合规性问题，包括身份验证、运行时保护和合规性。因此，例如，在身份验证方面，平台应提供：
- OAuth 2.0/Open Authorization/OpenID Connect (OIDC)；
- 用于服务网格的 mTLS；
- API 密钥轮换；
- 零信任验证。
运行时保护包括：
- DDoS 缓解；
- SQL 注入阻止；
- 每个客户端的速率限制；
- 载荷加密。
平台应解决的合规性问题包括清单证明、身份验证类型报告、与安全工具集成以及审计日志。
第五支柱包括开发人员体验以及包含对开发人员有帮助的功能的步骤，例如：
- 浏览现有 API 的目录；
- 从模板和 SDK 生成；
- 预配置身份验证/安全性；
- 自动合规性检查；
- 一切自助服务。
Ehmke 说：“如果你将所有东西都作为专有代码，或者让一切都成为‘选择你自己的冒险’，你就会遇到很多阻力。”“但如果你为开发人员提供简单的上手体验，让他们上传规范，获得一个代理，我向你保证，会有更多人敲门说：‘我想使用你们的新代理，因为它太容易使用了，我开箱即用就能获得所有东西。’”
最后，第六支柱涵盖监控和指标，并集成到一个 API 仪表板中，该仪表板可以向开发人员显示 API 总数、合规百分比、平均响应时间、安全问题、API 重用率和开发人员满意度。
Jason Ehmke 在 Kong API Summit 2025 上的演示截图。
避免陷阱
Ehmke 警告说：“现在，所有这些都可能存在一些潜在的陷阱，因为你可能没有获得支持，或者没有获得正确的支持。”“当然，你有你的平台，但你没有和安全团队谈过。你没有得到他们的许可。”
导致问题的五个最常见的陷阱是：
- 缺乏高层支持，导致人们忽视要求。高管需要制定硬性规定，例如 CISO 要求没有安全措施的 API 就不能部署。
- 另一个典型的错误是他称之为“网关剧场”，即假设只要有了网关就安全了。
- 还有——我们确信你听说过——一个常见的陷阱是“副总裁例外”，即某个副总裁因为赶截止日期而“就这一次”破例。这会导致混乱。因此，务必记录任何例外情况。“如果有人坚持要求例外，那么现在书面责任就在他们身上了，”他说。
- 让团队手动完成所有工作以规避 CI/CD 管道，这将阻止不良或不安全的应用程序。
- 开发人员的反抗也是一个潜在的陷阱。同样，自动化和良好的开发人员体验将有助于避免这种陷阱。
“自动化，自动化，自动化，这就是开发人员体验，”他说。“如果上手体验如此顺畅，开发人员会想办法让他们的副总裁同意不使用它，而你又会回到原点。”
