Linuxeden开源社区作者 ，译者 张卫滨
MuleSoft业已成为OAI的成员，并发布了能够同时理解RAML和 OAS的API模型框架。Restlet Studio如今已经支持RAML。
目前，有三个主要的HTTP API规范在竞争：Open API Initiative（OAI）基于Swagger所提供的Open API Specification（OAS）、MuleSoft作为主要贡献者的RAML以及Apiary所支持的API Blueprint，Apiary公司今年已经被Oracle收购。这三个规范都有自己的优点和相关工具，但是在2015年Swagger托管给Linux基金会之后，OAS获得了社区的主流支持。OAS从一开始就得到了3Scale、Apigee、Google、IBM、Microsoft、PayPal以及其他厂商的支持。
HTTP API领域在未来将会如何演化尚不明晰，但是最近发生了一些很有意思的事情。其中有一件事就是MuleSoft最近宣布加入OAI。MuleSoft的CTO同时也是RAML的创建者Uri Sarid已经开始参与OAI技术开发者社区并认为“每个人都应该支持一种通用的格式，它至少要能够描述API的服务模型”，这种格式应该是“目前采用最广泛的，即OpenAPI规范。”
鉴于MuleSoft依然“致力于支持RAML倡议及其投资，并且在扩大该生态系统”，我们可以得出结论，Sarid在OAI TC的主要目的是推动OAS的开发采纳RAML目前已经支持的一些特性：API建模、支持模块以及分离API协议的关注点。至于OAI TC会从RAML上借鉴多少内容尚有待观察。为此，MuleSoft已经开源了API建模框架，这是一种与API交互的方式，还包含对API的建模，以及随后生成RAML或OAS文档。实际上，我们可以将RAML定义的API，对其进行解析并生成相应的OAS文件。
MuleSoft的API建模框架依然是“alpha”和“实验性”阶段，Restlet是OAI的初始成员之一，最近又加入了RAML工作组，发布了新版本的Studio，能够同时支持OAS和RAML。Restlet的创始人Jerome Louvel阐述了RAML对OAS的影响：
与其让这三种方案进行直接的竞争，我们还是希望其中有一个能够获胜，取代另外的两个，有必要也有可能采用一种更好的演化路径。这个过程中的主要参与者和构建工具，比如Restlet Studio，同时支持OAS和RAML，并且会倾听用户的需求，我意识到理想状况是让Apiary和MuleSoft加入Open API Initiative，并逐渐做出贡献，使其变得收敛，而不一定要将这三个规范合并在一起…
在即将发布的OAS 3.0之上，我设想未来的RAML释放版本会扩展OAS规范，以捕获目前通过RAML 1.0表述的API建模信息。它将会让OAS核心更加简单和专注，同时还能够让API建模工具之间实现更好的交互，有助于保护API团队在设计之时所做的投资。Restlet是OAI的创始成员，最近又加入了RAML工作组，我希望能够直接为这些目标作出贡献。
确实，Apiary去年加入了OAI，并且为他们的工具添加了对Swagger的支持。HTTP API领域似乎正在围绕OAS进行整合。这意味着将来会有一个API规范，用户创建互操作的API会更加容易。至于RAML和API Blueprint会对OAS带来多大的影响，尚有待观察。