随着行业的发展，必然会出现标准，以实现更好的工程设计和使用。
自古以来就是如此。无论是罗马运河的几何复杂性、埃及金字塔的三角形对称性，还是印度寺院的空间和谐性，标准和规范都帮助工程师为可持续工程制定了独特的规则。
标准有助于提供共同的沟通和开发框架，并使我们能够根据特定需求选择合适的工具。
在 RESTful API 世界中，API 定义的标准是 OpenAPI 规范 (OAS)。
OAS 基于最初的“Swagger 规范”，在 API 开发中获得了巨大的吸引力，我们看到成千上万的 API 开发人员和使用者正在采用它。
但为什么是现在？为什么世界突然拥抱 RESTful 架构的标准规范，而几年前，REST 爱好者几乎完全反对用规范来定义 REST？
REST API 的新时代
API 不再局限于应用程序的后端。早在 PC 出现之前，API 就已经存在，将不同的逻辑单元连接在一起。
过去，API 并非供很多人使用。API 是数据驱动的，旨在解决一些特殊的连接和通信用例。文档很少（如果有的话），使用的规范直接来自核心数据库的行话，这意味着小网络之外的人无法理解它们。
毋庸置疑，过去的 API 并非用于自助服务消费。
以上不再适用于现代 Web API。我们正处于一个新时代，在这个时代，API 不仅允许企业更快地构建和扩展，而且还通过集成和使用第三方服务来实现共享收入和增长，从而推动战略和业务目标。与它们的前辈不同，新时代的 REST API 不是数据驱动的，而是更多地由消费者驱动。
解决实际消费者问题的精心设计的 API 是关键，我们看到 Dropbox、Stripe 和 eBay 等公司的 API 都专注于此。现在，许多公司都需要基于 HTTP 标准的可重用接口，以便重用数据和功能，并为消费者需求和自助服务而构建。
进入 OpenAPI 规范 (OAS)
OAS 对 REST 的意义就像 WSDL 对 SOAP 的意义一样。它为设计人员、开发人员、测试人员和 DevOps 提供了一个共同的框架来构建和维护 API。可以将该规范视为构建和实现 REST API 的一组规则。OAS 与语言无关，既是人类可读的，也是机器可读的，这使得人和计算机都可以在无需访问源代码、额外文档或检查网络流量的情况下发现和理解服务的功能。
所以，我们知道 OAS 可以帮助您构建以消费者为中心的 API，但是如何在开发生命周期中最好地使用该规范呢？
OpenAPI 驱动的 API 开发
定义驱动的 API 开发提倡在实施任何其他生命周期操作之前首先设计 API 的定义。这意味着即使在您开始构建 API 的业务逻辑之前，在您测试 API 是否有任何错误或缺陷之前，或任何其他生命周期功能之前，您都将设计 API 的接口，详细说明您的 API 端点将展示的确切请求和响应。
OAS 驱动方法的好处
定义驱动的方法带来了一些巨大的好处，这些好处直接关系到以消费者为中心的 API 开发方法。
- 更好的开发者体验 (DX)：DX 是开发者在消费和集成您的软件时可能体验到的所有体验的总和，包括积极的和消极的体验。在竞争激烈的 API 生态系统中，良好的 API 消费开发者体验至关重要。您实际上可以预先关注 API 消费者的需求。这使您能够采用以开发者为中心的方法，并确保在时间和其他开发方面竞争之前，以最佳方式满足最终消费者的需求。
- 实现独立性：该方法减少了在 API 上工作的不同团队（如前端和后端团队，或架构师、技术作家和 QA）之间的依赖关系。这是因为 API 的定义使各个利益相关者在 API 的预期功能及其与他们工作职能的关系上保持一致。它可以充当 API 的预期服务与其功能之间的合同，并确保它们之间更容易沟通。
- 更快地上市：由于消除了依赖关系，不同的团队实际上可以更快、更高效地执行其功能。团队之间的交接过程明显更容易，这使得您的 API 能够以更快的速度发布。
结束语
现代 API 不再符合传统的数据中心的世界观。软件和硬件应用程序都已连接，而 API 是这场数字革命的中心。为了连接这些应用程序，我们需要真正的人类开发者来了解您的 API 的功能，这就是为什么以消费者为中心的 API 视图正在迅速流行起来的原因。
OpenAPI 规范通过定义驱动的方法，帮助您实现解决潜在客户需求的 API，同时确保良好的开发者体验。
您现在可以观看关于 API 开发定义驱动方法的点播网络研讨会。在接下来的几个月中，我将继续撰写更多文章，详细解释 OAS 定义如何帮助不同的 API 生命周期功能，如 API 设计、文档、测试和监控。