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 带来多大的影响，尚有待观察。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论