昨日，RAML 的创建者 MuleSoft 宣布加入 OpenAPI 倡议。OpenAPI 倡议由 SmartBear Software 创建，基于广受欢迎的 Swagger 规范，是一个拥有包括 Adobe、IBM、Google、Microsoft 和 Salesforce 在内超过20个成员的 Linux 基金会项目。
对于 API 行业的关注者来说，这显然是向 OpenAPI 规范 (OAS) 趋同的明确信号。RAML 将继续在 OAS 之上提供额外的建模功能，但最终的契约很可能通过 OAS 实现。Apiary（现已成为 Oracle 的一部分）于 2016 年加入了 OpenAPI 倡议，将其以文档为中心的 Blueprint 格式带入 OAS 的支持之下。
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]
更新： 此帖子已更新，旨在澄清一些事实并解决一些潜在的误解。