昨天，RAML 的创建者 MuleSoft 宣布，他们已加入 Open API Initiative。OpenAPI Initiative 由 SmartBear Software 创建，并基于广受欢迎的 Swagger 规范，是一个 Linux 基金会项目，拥有 20 多个成员，包括 Adobe、IBM、Google、Microsoft 和 Salesforce。
对于 API 行业的关注者来说，这应该是一个明显的信号，表明 OpenAPI 规范 (OAS) 正在趋同。RAML 将继续在 OAS 之上提供额外的建模功能，但最终的契约很可能会通过 OAS 进行。Apiary（现已成为 Oracle 的一部分）于 2016 年加入了 Open API Initiative，将 OAS 带回其以文档为中心的 Blueprint 格式。
Swagger (OAS) 如何成为标准？
回顾过去，最迫切的问题是，OAS（通过 Swagger）如何以轻量级、社区为根基的形式，在 2013 年至 2015 年之间的“伟大的 API 描述之战”中脱颖而出，成为领先的格式？（而且这一切在 Swagger 于 2015 年初迁移到 SmartBear 之前，都没有正式的公司支持？）
这里面有营销、工具、(不得不承认) 绝妙的名称等因素。但是，如果我退一步，忽略所有这些因素（这并不容易），而只关注规范本身，就会清楚地看到为什么 Swagger 赢得了这场战争，而其他规范都向它靠拢。
Swagger 最初的目标很少，并且涵盖所有用例肯定不是其中之一。因此，Swagger 的创始者在构建该项目时设定了三个简单的目标
- 具有可读性。 这意味着规范必须简洁、有条理且足够清晰，以便“普通”人可以理解它。
- 具有机器可读性。 这需要结构和“规则”，以便计算机可以解释规范本身以“执行某些有用的操作”。
- 足够全面，可以描述使用或生成 REST API 所需的一切。
虽然最初的 1.0 Swagger 规范存在一些缺陷，但它肯定遵循了上述规则，因此我们能够构建非常强大且有价值的工具来利用它。
这与当时的另外两种主要格式有何不同？
很简单
- API Blueprint 是一种非常清晰的文档格式。 它主要面向人类，并且仅限于 markdown。后来开发了工具，允许以不同的格式进行创作，但这显然侧重于文档而不是描述。有什么区别呢？这就像阅读法律文件的摘要与阅读文件本身一样。虽然它在文档方面很受欢迎，但机器可读结构、严格的模式和“可操作的扩展”的概念似乎与 markdown 无法很好地配合使用。
- RAML 中的“ML”代表“建模语言”。 这意味着 RAML 的设计目标是能够建模大量的 API，但这可能不是任何特定 API 或开发人员所需要的。他们所需要的都是一种以明确的机器可读方式描述契约的约定俗成的方法。
这对于未来意味着什么？
很多！但就像 20 世纪 90 年代末的伟大的浏览器之战一样，我相信我们看到 API 的单一描述方言正在趋同。这是一件好事（我们中的一些人还记得“此网站只能在 Netscape Navigator 中工作”的消息），因为最终，API 的使用者通常不关心它们是如何被描述的。如果机制标准化，并且更多的“东西”可以通信，那么每个人都会赢。
看到业界围绕 OAS 团结起来，我感到很满意，现在 RAML API 规范可以表示为 OAS 契约，我们可以在整个 API 生态系统中从这些契约中获得全部价值，从而为机器对机器通信提供共识，更重要的是，推动 API 生命周期。
我们进行了许多公开辩论，并且投入了数千小时的个人时间在项目中；事实证明，在一开始就设定正确的目标是赢得 REST 社区支持的关键，因此我们期待与 MuleSoft 的 RAML 团队合作，以利用他们在持续 OAS 工作中的领域专业知识。
[caption id="attachment_694" align="aligncenter" width="310"]
2013 年伟大的 API 格式之战期间，与 RAML 创建者 Uri Sarid、API Blueprint 创建者 Jacob Nestril 和 Swagger 创建者 Tony Tam 进行了许多以 IPA 为燃料的公开辩论之一[/caption]
已更新： 此帖子已更新，以澄清一些事实要点并解决一些潜在的误解。