MuleSoft加入了OpenAPI项目:API规范战争的结束

时间：2017-04-21 作者：Tony Tam

  昨天，RAML的创建者MuleSoft宣布他们已经加入了OpenAPI倡议。OpenAPI是由SmartBear软件公司创建的，基于广泛流行的Swagger规范，它是一个Linux基金会项目，拥有超过20个成员，包括Adobe、IBM、谷歌、微软和Salesforce。

  对于API行业的追随者来说，这是显而易见的，这是OpenAPI规范(OAS)上的一个清晰的信号。RAML将继续在OAS之上提供额外的建模功能，但是最终合同很可能是通过OAS来实现的。作为Oracle的一部分，Apiary在2016年加入了开放API项目，让OAS支持他们的文档集中的蓝图格式。

Swagger (OAS)是如何成为标准的?

  回顾过去，问题在于，在2013年到2015年之间的“大API描述战争”中，OAS(经由Swagger)作为轻量级的，社会主流的格式，是如何形成的?(所有这些都没有正式的企业支持，直到2015年初，Swagger 转向SmartBear?)

  有市场营销、工具、(当然是不可思议的)名称等等，但是如果我退一步，忽略所有这些因素(这并不容易)，并且只关注规范本身，那么就有一个明确的理由说明为什么Swagger赢得了战争，而其他的则仰赖于它。

  Swagger是以少数几个目标为起步的方向的——并且覆盖每一个用例当然不是其中之一。在此基础上，Swagger的开创之父为这个项目建立了三个简单的目标:

• 人类可读的。这意味着规范必须简明、有条理、清晰，使“正常”的人能够理解它。

• 机器可读的。这需要结构和“规则”，这样规范本身就可以被解释为计算机“做一些有用的事情”。

• 要彻底地描述所有需要消耗或生成REST API的内容。

  尽管最初的1.0 Swagger规范有它的缺点，但它确实遵循了上面的规则，因此我们能够构建非常健壮和有价值的工具来利用它。

这与当时的其他两种主要格式有什么不同呢?

简单来说：

• API蓝图是一种非常干净的文档格式。它是为人类而存在的，被限制在markdown中。后来开发了工具以允许以不同的格式进行创作，但这显然是侧重于文档而不是描述。有什么区别呢?这就像阅读法律文件的摘要和文件本身一样。虽然在文档方面很流行，但是机器可读结构、严格的模式和“可操作的扩展”的概念似乎并不适用于markdown。

• RAML中的“ML”代表“建模语言”。这意味着RAML的设计目标是能够对大量API进行建模，但这可能不是任何特定的API或开发人员所需要的。他们所需要的是一种商定的方式，以一种明确的机器可读的方式来描述契约。

这意味着什么呢?

  很多!但就像20世纪90年代末的浏览器大战一样，我相信我们将会看到统一的对api的描述的单一方言。这是一件好事(我们中的一些人仍然记得“这个站点只在网景领航员（网景浏览器）中工作”)，最后，api的消费者通常不关心他们是如何描述的。如果这个机制是标准化的，更多的“东西”可以相互交流，那么每个人都会赢。

  看到围绕OAS的行业集会是令人满意的，现在RAML API规范可以表示为OAS契约，我们可以从这些契约中获得整个API生态系统的全部价值，为机器对机器的通信提供一致规范，更重要的是，它可以驱动API的生命周期。

  我们已经做了很多公开的讨论，并且有成千上万的个人时间投入到这个项目中;在开始的时候设定正确的目标是赢得REST社区核心的关键，因此我们期待与MuleSoft的RAML团队合作，在正在进行的OAS努力中利用他们的领域专业知识。

原文链接：

• MuleSoft Joins the OpenAPI Initiative: The End of the API Spec Wars