API流量爆炸！80%企业AI将用MCP。构建更好API，拥抱AI驱动的OpenAPI规范，快速Mock，工作流测试是关键。本地开发远程测，共享类生产环境提速，DevOps效率翻倍！
译自：5 'Cheat Codes' for Building Better APIs
作者：Heather Joslyn
惊人的互联网流量——根据您相信的数据，在 70-80% 的范围内——来自 API 调用。
但是，虽然 85% 的开发人员报告构建或维护 RESTful API，但只有大约 50% 的受访开发人员表示他们使用 OpenAPI 规范，根据 Postman（API 平台公司）的 2023 年数据。
这意味着什么？Matthew Voget（Ambassador 的工程副总裁）表示，这有很多危险信号。
“我们有太多的 API，但规范不足，”Voget 在上周四在 APIDays New York 上的演讲中说。
在这种情况下，再加上 模型上下文协议 (MCP) 的出现，这是一种旨在简化 AI 模型和 API 交互方式的开源标准。他指出，分析公司 Gartner“报告称，到 2028 年，80% 的企业 AI 代理框架将使用 MCP 侧面的服务发现方式。
“那么，将这第三层添加到其中，你会得到什么？”Voget 问道。“您有很多 API，互联网上通过 API 完成了大量流量，并且可能有大量 AI 代理使用这些 API。”
由于大量 AI 代理使用这些缺乏标准化规范的 API，Voget 说，提出了一个“更大的危险信号”。“如果您没有高质量的 API 规范来告诉您这种交互的行为方式，您如何知道这些 AI 代理正在访问什么类型的数据？”
他表示，目前的情况归结为两个主要挑战：缺乏 API 规范和开发循环不足。为了帮助开发人员克服这些障碍，Voget 为 APIDays 的观众提供了五个“秘籍”，用于在 AI 代理时代构建更好的 API。
Voget 建议，在没有 OpenAPI 规范的情况下构建 API 可能会阻碍组织充分利用 AI 代理 和相关创新。
“我已经看到这里有六家公司表示他们会将您的开放 API 规范转换为 MCP 服务器，”他说。“除非您有开放 API 规范，否则您无法做到这一点。”
Voget 说，那些缺失的 API 规范可能会带来其他更潜在的危险漏洞，而不仅仅是错过最新和最棒的功能。“由于未经测试的代码或未经验证的 API，您可能会遇到错误。您的 API 之间可能存在集成问题。”
他说，安全漏洞也是这种情况下的一个大问题。“如果您没有在规范中描述 API，并且[开发者体验] 不佳，您可能不知道 API 是否受到保护。这不仅适用于与您的 API 交互的人，也适用于 AI 代理。”
Voget 说，开发循环（API 在开发过程中经历的过程）也可能带来挑战。
他提出了一个具有“外部”和“内部”循环的软件开发模型。“您可以将内部循环视为开发人员每天必须多次执行的操作，例如构建新的 API 或构建功能，”Voget 说。“他们会编写代码，构建代码，在本地测试代码。通常，他们会调试，然后最终提交。
“然后，这将进入外部循环，他们将执行诸如运行 CI 工作流程、进行集成测试以及最终部署到生产环境之类的操作。因此，如果您考虑一下，内部循环应该非常快，因为开发人员将多次执行此操作。他们将进行快速验证，尤其是在他们使用 AI 代码生成工具的情况下。”
但他补充说，这种软件开发模型需要权衡，这会对开发人员的生产力产生影响：速度与质量、自主性与技能。
“有时很难找到能够完成所有工作的独角兽开发人员，”他说。因此，“我们经常将这些团队进行隔离。我们有 DevOps 或平台团队，然后我们有我们的开发功能团队，但是这些孤立的团队可能会导致效率低下，尤其是在开发人员需要将某些东西部署到托管环境或远程环境中进行测试时。”
为了帮助克服缺少规范和低效开发循环的挑战，Voget 提供了五个“秘籍”，用于构建更好的 API。
利用 AI 的优势：遵循规则。 “我还不完全信任AI来编写我所有的代码，并期望这些代码没有错误，”Voget说。然而，“我更信任AI生成的内容是遵循像Open API规范这样的严格结构，然后说，‘嘿，使用模式匹配来填补我规范中的空白’，或者‘根据扫描我的代码文件为我生成这个规范，并让我达到那个规范。’”
Voget说，如果AI能够使开发人员更快地创建更高质量的API规范，那么他们也应该能够更快地启动这些API规范的模拟实例。
“Mock服务器对于支持并行开发非常有用，”他说。“也许你有一个前端团队正在开发UI，一个后端团队正在开发API。如果他们有一个描述该接口的高质量mock，他们就可以并行工作。所以我喜欢基于规范创建这些mock，而不是推出定制的mock服务器实现，因为这些mock服务器很难维护。”
“我们有，特别是对于微服务，一堆执行专门操作或只有几个端点的API，”Voget说。“我们可以设置这些契约测试来测试我们API的单元。但真正酷的是，Open API有一个Arazzo specification……Arazzo规范非常棒，因为它们可以测试API调用的工作流。”
他说，Arazzo规范可以帮助执行API工作流的功能测试。例如，“假设我有一个API来检索用户个人资料，但首先我需要进行身份验证以获取身份验证令牌。这是一个API调用。然后，也许我必须获取用户列表。这是另一个API调用。然后我终于可以通过ID获取用户个人资料，这是第三个API调用。”
Voget说，Arazzo规范“可以描述整个交互，这非常非常强大。如果我们采用Arazzo规范，我们可以基于这些规范设置这些端到端测试和集成测试。”
Voget说，前三个秘籍旨在解决缺少或不足的规范的挑战。后两个秘籍解决了开发循环/开发人员生产力挑战。
秘籍4的要点：你说你的机器上可以工作？证明它。
“我们如何将测试从我们的外部开发循环转移到我们的内部开发循环，使其更快？”Voget问道。“我们可以做的是设置一个远程、共享的开发环境的概念。”
他说，一些开发人员可能已经在他们的CI工作流程中设置了临时测试环境，“你可能正在编写一些东西，然后你提交一个pull request，然后我们启动一些远程环境来在其中进行测试。”
但Voget认为“我们可以将其进一步左移，并已经设置了一个开发环境，这样你只需要更改你的API代码，并且只需在使用远程资源（如你的UI或其他依赖项）进行测试时运行和测试你的API。Mock服务也可以真正帮助解决这个问题，特别是如果你托管共享的mock实例。”
他说，通过设置一个共享的远程开发环境，一个团队可以减轻“在本地运行整个应用程序的负担”。
Voget建议，关键词是“共享”：“不要再在只有你能访问的本地主机上运行所有东西。拥有这些共享的、可管理的URL，你可以给你的团队说，‘嘿，测试一下我的本地更改’，或者‘测试一下我正在推送到这个共享开发环境的更改’，甚至在我提交代码或将其推送到CI循环之前。”
“如果我们正在设置这个共享的远程开发环境，那么最棒的事情是，我们可以使其尽可能接近生产环境，”Voget说。“它是远程的。它很可能以与我们的生产环境相同的架构和基础设施构建。”
他指出，一个与生产环境非常相似的暂存或预生产环境是理想的；那么为什么不创建一个也模仿生产环境的开发环境呢？
Voget说，生产质量的开发环境应包括生产API网关，以及“我们需要运行完整应用程序的所有微服务和所有依赖项”。“我们甚至可以在提交代码之前进行高质量的测试。”
他说，秘籍5有助于解决API构建者（以及一般的开发人员）在质量和速度之间面临的权衡。“我们实际上可以两者兼得，”他说。“我们可以拥有一个快速的开发循环、内部开发循环，并且还拥有一个高质量的测试环境来测试我们的更改。”