作者：Kin Lane，Postman 首席布道师
在当今的商业环境中，为企业和消费者提供金融服务的复杂性难以言喻。API 是提供产品和服务的重要组成部分。
Plaid 的使命是通过技术实现金融服务的民主化，它是一家为开发人员构建金融科技领域应用程序提供 API 的公司。Plaid 的平台允许应用程序连接到用户在银行和其他金融机构的账户。消费者和企业可以利用各种 Plaid 支持的应用程序来快速轻松地转账、分析支出、申请贷款等等。
基于新的 OpenAPI 规范 3.1.0，Plaid 构建了一个 API 文档，允许他们轻松发布其客户端库的更新（他们支持五种：Ruby、Node、Python、Java、Go）。而且，他们已发布了一个 OpenAPI 文件，用于自动生成您首选编程语言中的自己的客户端库，使您能够轻松地用 40 多种不同的语言自动生成自己的客户端库——因此，无论您使用哪种语言，都可以轻松地使用 Plaid 进行构建。
OpenAPI 之旅
Plaid 的 OpenAPI 之旅并非始于某个人或某个团队，而是源于多个团队，他们出于不同的动机需要一个单一的机器可读的事实来描述他们的银行 API。我最近与 Plaid 开发者关系团队的 Alex Hoffer 进行了交谈，以了解更多关于 Plaid 选择使用 OpenAPI 规范的动机，并了解他们是如何走到今天的。
Plaid 最近将其OpenAPI 发布到 GitHub 存储库，我认为这是一个与他们联系并讨论他们采用 OpenAPI 规范的情况以及他们是否愿意与我们分享他们的故事的绝佳机会。他们同意了！因此，感谢 Plaid 团队与我们交谈，并分享 OpenAPI 如何在银行 API 平台的 API 操作中应用的详细信息。
更快地创建更好的文档
与大多数 API 提供商一样，Plaid 采用 OpenAPI 规范 (OAS) 的首要原因是为其公共 API 提供文档。Plaid 的文档已经使用了一段时间，需要进行更新，因此开发者关系团队着手进行彻底的重写，并且他们希望确保能够使他们的文档面向未来，以便他们能够随着 API 的发展而发展。在研究了现状后，很明显，OpenAPI 规范 (OAS) 是以可扩展的方式描述 Plaid API 的最有效方法，并且它可以支持其银行 API 文档的当前和未来状态。Plaid 团队继续彻底修改了他们的文档，并且在他们努力为 Plaid API 文档提供完整的 OpenAPI 时，其他团队也正在将 OpenAPI 用于 Plaid 平台的各个角落。
交付客户端库
当开发者关系团队正在处理 Plaid OpenAPI 文档时，他们的开发者体验团队也在努力了解如何使用它来跨多种编程语言交付 API 的客户端库。Plaid 的开发者体验团队每两周发布一次 API 的多个 SDK，这是一个手动过程，需要大量的工作并且容易出错，同时也需要在每种语言中具备丰富的专业知识才能交付最佳的 SDK。在所有这些工作中，开发者体验团队非常希望能够尽可能地自动化该过程，但是当他们开始从 OpenAPI 生成 SDK 时，他们意识到该过程将需要一个更加健壮和完整的 OpenAPI 来提供每种语言库所需的所有详细信息。最终，该团队花了五个月的时间才交付了一套符合团队期望的 Beta 版 SDK，但现在他们拥有了一种更加简化的跨多种语言交付 SDK 的方法，同时还确保 SDK 发布过程始终与 API 文档的发展保持一致，因为两者都源于同一个机器可读的事实——Plaid OpenAPI 合同。
JSON Schema 现已可用
除了 Plaid 的开发者关系和体验之外，核心服务团队也注意到了用于支持文档和生成客户端 SDK 的 OpenAPI。该团队对 Plaid API 的机器可读事实的集中化很感兴趣，但尤其对现在可用于描述每个 API 的请求和响应有效负载的 JSON Schema 感兴趣。当涉及到引入对用于支持平台的模式的更改时，内部开发人员会感到焦虑，并且由于对任何版本中可能出现的重大更改的可见性有限，开发人员会留下很多问题。由于现在作为 OpenAPI 的一部分提供了集中式 JSON Schema 定义集，因此内部开发人员现在可以使用它们在 Plaid 平台上的管道和中间件中进行验证，确保正在进行的更改不会更新或删除可能导致 API 和集成下游应用程序出现错误的任何属性。利用中央 OpenAPI 来帮助使版本发布更加可靠，并减少内部开发人员引入新功能和功能时推动 API 平台前进的压力——减少了 Plaid 平台的摩擦。
定义扩展
随着 OpenAPI 引入 Plaid API 的文档、验证和 SDK 交付中，团队能够立即利用许多好处。但是，所有三个团队都很快开始遇到 OpenAPI 规范能够定义的内容的限制。其中一些需求对于 Plaid 的做事方式是独一无二的，但其他需求类似于您在其他 API 提供商中看到的许多常见需求。这并没有减缓 Plaid 团队的速度，他们很快开始为 OpenAPI 定义扩展，这将帮助他们定义文档所需的内容，也满足多种编程语言中生成 SDK 的严苛需求。最值得注意的是，他们还建立了一个 x-plaid- 扩展，用于描述将在 OpenAPI 定义随时可用于 Plaid 社区时从中剥离的内部模式和功能。这项工作确实帮助 Plaid 意识到，当您扩展和推动规范以完全满足您的需求时，OpenAPI 规范真正大放异彩，允许其 API 的机器可读事实有效地交付 API 生命周期中的多个重要环节，例如文档、SDK 生成和验证。
客户请求 OpenAPI 规范
Plaid 的 OpenAPI 之旅反映了许多 OpenAPI 采用者已经体验过或正在体验的内容。虽然 API 提供商采用 OpenAPI 的动机有很多，但需要为各种编程语言提供始终最新的 API 文档和 SDK 是排名前两位的动机。这段旅程通常始于提供更好文档的需求，但随着团队意识到相同的 OpenAPI 可用于支持 API 生命周期中的其他环节，他们真正看到了 API 规范作为 API 单一数据源的潜力。很高兴听到 Plaid 使用 OpenAPI 的背后故事，希望这个故事可以让你了解 OpenAPI 在 Plaid 中可以做什么的“已知已知”，但当我结束与 Alex Hoffer 的谈话时，我问她为什么他们将他们的 OpenAPI 发布到 GitHub——这最终是这次谈话的催化剂。她只是说，OpenAPI 是客户的常见请求，这样他们就可以为他们不支持的语言生成自己的库，而且在与该领域的其他领先 API 提供商交谈后，他们提到他们对社区使用 OpenAPI 做出的独特事情感到惊讶，这些创新超出了内部团队所能提供的范围。这真正体现了为您的 API 社区提供 OpenAPI 最强大的原因，因为它将为使用您的 API 提供全新的方法，这正是我们一开始创建 API 的原因。OpenAPI 只是在放大这种效果，并将事情提升到全新的水平。