只有当有创新的支持时，技术才能普及大众。以 iPad 为例。虽然平板电脑的概念在 2010 年 iPad 发布之前就已经存在多年，但苹果公司之所以能成功推出 iPad，部分原因是当时 WiFi 连接的普及。

如果连接的普及能够使平板电脑成为现实，那么描述格式的普及则能使 API 在商业上获得成功。 OpenAPI 规范（OAS）已成为世界上 RESTful 接口的标准描述格式。 OpenAPI 规范是 REST API 的人类友好型、机器可读的接口。 OpenAPI 规范描述了 API 的功能，包括 API 公开的资源及其相应的请求和响应。

这种格式使得 API 的内部利益相关者及其外部消费者之间的访问和协作成为可能。简而言之，OpenAPI 规范改变了 API 的构建和交付方式。

OAS 由 Linux 基金会下的 OpenAPI 倡议（OAI）管理。作为 Linux 基金会下的开放治理结构，OAI 专注于创建、发展和推广供应商中立的描述格式。

我有机会在今年的 API 战略与实践大会 APIStrat 2017 上与 OAI 技术指导委员会（TSC）成员 Darrel Miller 进行了交谈。 Darrel 分享了关于 OAS 项目当前状态的宝贵见解，以及业界如何接受最新版本的规范 OAS 3.0。

OAS 3.0 的当前状态

OAS 3.0 今年早些时候发布了？ 到目前为止，您收到的反馈如何？

到目前为止，反馈非常积极！我们对结构进行了一些很好的清理和重组，只是为了使规范更具可读性。令人欣慰的是，我们在 OAS 3.0 中所做的一些更改使我们与 HTTP 的工作方式更加一致，并使许多开发人员能够充分发挥其全部功能。

我们确实收到许多人对 WebHooks 和链接功能感到兴奋。链接功能是一个非常有趣的通配符。我认为有可能用它来做很多很酷的事情。许多人错误地认为我们试图体现超媒体，这是一个与人们进行的有趣的对话，特别是考虑到我在超媒体方面的背景。

OpenAPI Spec 3.0 正在解决那些喜欢使用静态设计原则构建 API 并定义 API 中操作和资源之间关系的公司的一个实际需求。它绝对已成为一个关键的基础设施。

我认为 OAS 3.0 也有可能极大地改进 API 的文档，因为突然之间，您现在可以描述通过 API 的流程。我认为场景是描述和记录 API 的更好方法，而链接可以帮助我们沿着实现流程之间文档自动化的道路前进。我很想看看人们将围绕它构建的一些工具。

我个人很希望看到更丰富的 API 文档用例和资源之间更好的关系处理。

我的意思是，当您访问一个 API 时，您应该如何使用它？那么我从哪里开始？那里有 150 个资源和一个很长的字母列表，您必须开始查看路径结构并确定它的含义并尝试从中推断。然而，如果您可以实际告诉您的消费者，“好吧，这里是您的起点，从这里您可以去请求信息。”

您不必遵循该路径。您可以跳转到那些终点，但至少对于理解 API 的组成方式，这是对 API 结构方式的语义的重大补充。

采用是任何技术努力的一个重要组成部分。 OAI 如何教育和传播有关 OAS 3.0 的信息？

我认为在工具支持还不成熟的时候，您不想过早地进行大规模的推广，但是看到到目前为止的采用情况令人高兴。我们意识到 OAS 获得大规模采用的唯一方法是通过更多的工具支持。我们在 GitHub 项目上有一个实现页面，其中列出了所有支持 OAS 3.0 的工具。看到此列表每天都在增长，这非常令人兴奋。

在围绕 OAS 的工具方面，我们看到了不同技术的良好传播；从 Ruby 和 NodeJS 到 .NET 和 JavaScript。

为了进一步支持我们的营销活动，我们与一家营销和品牌公司签订了合同，以提高对 OAS 的认识。我们还考虑过宣传，但我认为现在还为时过早，因为我们仍在确保我们获得所有正确的工具来支持 OAS 必须提供的所有功能。

APIStrat 2017 是 OAI 赞助的第一个大型活动。您在今年的会议上注意到了什么？

显然，今年的 APIStrat 更加重视 OpenAPI。我希望这仅仅是因为在过去的 12 个月里，我们发布了新版本的规范，并且 API 领域所有人的共识终于围绕 OpenAPI 作为 REST 接口的标准描述格式而统一起来。我认为我们都知道拥有 API 描述的价值，最后我们可以停止争论哪个是最佳格式。我们实际上可以开始在该生态系统中获得越来越多的工具。

规范和工具的演变

由于不同的组织对 OAI 投入了大量资金，这如何增强了规范的演变过程？

它根本没有发生显著变化。 OAI 的架构旨在确保社区中每个人的声音都能被听到。当成员公司加入该组织时，他们基本上是在公开声明他们支持 OAS，而不是在其发展中发挥影响力。 OAI 的成员资格与规范构建的技术方面完全独立。

任何在 API 方面有任何利益的社区成员都可以根据需要做出贡献。您不需要成为会员即可为规范做出贡献，就像您不需要成为会员即可阅读、使用和受益于规范一样。

让行业公司加入 OAI 对于势头、提高在该领域的知名度以及确立 OAS 的可信度非常有帮助。然而，从技术角度来看，它没有任何直接的关联。从技术角度来看，重要的是让更多的人加入。我们将专注于尝试让更多核心人员加入指导委员会。已经有许多人为该项目做出了广泛的贡献，我们希望提名并邀请这些人加入指导委员会。这将使他们对规范中的内容有更多的发言权，并帮助我们接触更多社区成员以获得更多意见。

为了让更多的人做出贡献，我们在完成 OAS 3.0 后花了一些时间进行整理并使我们的管理工作步入正轨。我们正在制定开发人员指南，以向想要贡献的人明确我们推荐的那种流程。

最初版本的规范，即 Swagger 规范，由于存在大量的工具而非常受欢迎。展望未来，OAI 是否有计划与更多的供应商合作？

我们一直在尽一切努力鼓励更多人开发工具，并且 OAI 的一些成员正在开发工具。我们对 OAI 的角色和职责以及工具之间有相当严格的划分。我们只负责规范的管理。我们不希望官方组织拥有自己的工具。所有的工具都是第三方开发的；我们只是负责创建规范。

到目前为止，我们不需要说服人们开发工具，因为公司正在自然地开发工具。其中很多只是对生态系统中现有工具的更新。问题只是我们需要完成规范，并且人们需要时间来吸收它，并能够展示迁移到 3.0 的价值。

在您网站上发布的博文中，您提到您最初对 OAS 持怀疑态度。您是否曾想过最终会与 OAS 合作？

不，我从来没有想过我会加入 OAI。我在小组讨论中也说过，这并不是从技术角度来看架构模式的正确性问题，而是它对实际工作流程的影响。从我的博文中，你会看到我曾经是，而且现在仍然是超媒体的倡导者。

当你使用 OAS 拥有一个静态设计的 API 时，你会获得一些好处——比如能够生成文档脚手架和生成客户端——但会失去一定的灵活性，这迫使你制定一个版本控制策略来随着时间的推移进行演进。

这是静态设计和动态设计之间的权衡，我想在某种程度上我意识到，我更愿意成为解决方案的一部分，以帮助绝大多数开发人员构建更好的 API，即使他们选择了一条版本控制的道路而不是可演进的道路。

绝大多数公司都在采用更简单的方法，并利用静态 API 描述的优势。我很高兴参与到这个倡议中，公司从中获得了巨大的价值。任何我可以在指导 OpenAPI 规范的未来发展方面做的事情，以便我们可以避免某些陷阱，那么我很高兴能够参与其中。

您认为 OpenAPI 是否会发展到支持其他框架或架构，如 GraphQL？

HTTP 被设计为具有可扩展性点，其中一种体现形式是媒体类型。Webhooks 非常棒，因为 webhooks 自然地融入了 HTTP 模型。

GraphQL 定义了一组可以很自然地成为媒体类型的东西。一个用于查询的媒体类型，一个用于结构化响应的媒体类型等。它们有自己的类型系统。如果现有的类型系统不满足你的需求，那很酷。 Web之所以如此成功，是因为它在请求之间，在您层次结构中描述的资源之间以及您可以发送回的有效负载之间具有非常好的关注点分离，这些有效负载是完全独立的。

回到 OAS 可以做什么，如果任何架构风格被构建为很好地适应 HTTP 而不是试图在 HTTP 之上分层，那么它就适合 OAS。我喜欢创新，人们正在做事情。GraphQL 本可以很好地适应这一点，并与我们现有的所有技术协同工作。我真正希望看到他们做的是以一种更自然地适应 HTTP 生态系统的方式构建它。

我能看到的唯一另一种适合 OAS 的主要风格是 RPC 类型的 API，您实际上是将操作作为请求主体的一部分进行隧道传输。这对我们来说仍然是一个挑战，因为我们使用路径来识别操作。我一直在思考如何使操作被路径以外的其他东西识别。例如，在 OAS 3.0 中，我们有这个新的运行时表达式，可以利用它。现在，我不确定这将如何工作，因为那时你会有很多操作都具有相同的运行时表达式。它可能有不同的操作 ID 来唯一标识这些操作，也许？但问题是，在那一点上，我们是否离 HTTP 的工作方式太远了？

这里有一些非常有趣的对话可以展开，特别是关于我们如何在不开始用并非每个人都认为有价值的东西污染规范的情况下，扩大我们可以支持的范围。如果你开始做那些相邻的 RPC 的事情，感觉有点不太好，尽管我很想找到一种方法来支持那些想以多种方式设计 API 的人。

所以您刚才告诉我们，OAS 想要支持的任何新功能都需要适应 HTTP 的工作方式。这些功能的可用性也是一个考虑因素吗？

我的意思是，这对采用至关重要，对吧？我赞扬 Tony Tam（最初的 Swagger 规范的创建者）将很多内容融入到规范中。他总是会拒绝任何过于工程化或对最终用户来说过于复杂的东西。

我们现在让不是全职开发人员的人开始设计和构建 API，因此拥有一个易于使用的描述格式变得至关重要。我实际上与在 OpenAPI 聚会上的人交谈过，他们是业务分析师和产品经理，而不是经验丰富的开发人员。他们可能对实现 API 没有最好的想法，但他们了解 API 应该涵盖的业务案例场景。

结束语

我想以了解您在 API 领域最兴奋的事情来结束这次对话？

我想看看人们使用 OAS 3.0 的链接和文档做了些什么。API 文档可能会变得非常困难，甚至到了痛苦的地步。我希望那些具有更强的技术写作能力和比我更好的 UI 知识的人能够利用我们使用 OAS 构建的东西，并创建基于场景的文档脚手架生成器。

生成的文档只能带你走这么远，但基于场景的脚手架可以消除制作大量可消费信息的单调乏味。这就是我最感兴趣的事情之一。

然后我们可以继续在生成的内容之上添加额外的价值。这绝对是一个有趣的领域，我对未来感到非常兴奋。

有兴趣开始使用 OpenAPI 3.0 吗？查看我们的免费培训：OpenAPI 3.0 及其对 Swagger 未来的意义