OAI和API规范的简短历史

NEWS前沿动态

OAI和API规范的简短历史

来源：CPDA数据分析师网 / 作者：数据君 / 时间：2020-07-30

当时代码驱动是实现REST API的主要方法

此方法得到了各种REST API框架的支持，例如Sun Microsystems的Marc Hadley和Paul Sandoz创建的Jersey或我在2005年初创建的Restlet框架，但是随着REST API项目的成熟，对更多工具的需求开始出现。

根据SOAP时代WSDL的初步经验，Sun在同一家Marc Hadley上首次尝试正式描述称为WADL（Web API描述语言）的REST API ，并于2009年提交给W3C。它的继任者，但由于它对XML的依赖，甲骨文（Oracle）收购Sun之后缺乏开发以及其创建者Marc Hadley在2010年离职而受到阻碍。

不久之后，Tony Tam在Reverb启动了开源Swagger项目，以为其Wordnik API提供交互式API文档和客户端SDK生成。Swagger以其精美的可视化API文档而闻名，现在称为Swagger UI。它是一个Web应用程序，通过从API服务器提取JSON文档来动态检索API描述。

然后，开发人员开始动态地生成此JSON文档，例如，通过内省JAX-RS API或Restlet Framework API的Java代码以收集必要的API合同信息。非正式的Swagger JSON文档的重要性日益增加，Tony Tam意识到了这一点，他开始了将其正式化为Swagger规范的旅程。

在2013年左右，出现了三种竞争的API描述语言，每种语言都有不同的起点并提供了互补的观点。

Swagger Specification是草根Swagger开源项目的一部分，该项目专注于代码驱动的开发人员需求，除Apigee的重大贡献外，没有API供应商的正式公司支持。除了其技术质量外，它对描述核心API合同（JSON格式）的关注是其不断被采用的优势。

API蓝图是由雅库布·内塞特里尔（Jakub Nesetril）在黑客马拉松期间创建的，作为WADL和Swagger的更易理解的替代形式（Markdown格式），由Apiary于2013年发布，专注于以消费者为中心的API文档。该规范演变为涵盖了完整的API生命周期需求，并添加了用于模拟或测试的工具。尽管整个项目都以开源形式提供，但其他API供应商很难通过竞争对手API供应商的这种控制对其进行大量投资。

RAML也是由MuleSoft的Uri Sarid于2013年创建的，它是Swagger的替代产品，着重于人和机器的可读性（YAML格式），¬†顾名思义着眼于API设计（RESTful API Modeling Language）。开发它是为了满足大型API提供商的需求。尽管可以将RAML作为一个开放源代码项目，一个真正的社区的发展以及其他供应商的支持，但MuleSoft的强大实力限制了其被接受为标准的能力。

发布后发布，每个计划都改进了其规范和围绕它的工具，制定了自己的愿景，考虑了社区反馈，与其他规范区分开来，终在思想共享和吸引力上竞争。

随着2014年Swagger 2.0工作组在 GlueCon会议上的宣布，取得了重大进展，不仅超越了基层项目，而且更正式地制定了Swagger规范，以加快社区采用率。其他API供应商在其产品中以一种或另一种方式拥抱和嵌入了Swagger。

当SmartBear在2015年初收购Swagger项目时，人们对该项目保持供应商中立并继续其成功道路的能力感到严重担忧，但Tony Tam致力于保持该项目的开放。经过几个月的认真思考，SmartBear宣布将Swagger规范捐赠给Linux基金会，这是新的Open API Initiative的一部分，Open API Initiative由3Scale，Apigee，Capital One，Google，IBM，Intuit，Microsoft，Paypal， Restlet和SmartBear。该规范被更名为OpenAPI Specification（OAS），使Swagger项目专注于围绕OAS的开源工具。

在OAI中，Tony Tam领导了技术开发人员社区（TDC），保持了基层开发人员的精神，而SmartBear的CTO Ole Lensmar担任了商业治理委员会（BGB）的主席。凭借Linux基金会在促进此类计划（尤其是开放容器计划）方面的经验以及大量领先的API供应商的参与，OAI于2015年底启动。同时，API蓝图和RAML都在继续进步，我有幸在2015年采访了InfoQ的创建者，讨论了每项举措（请参阅对RAML的创建者Uri Sarid的采访，以及对API的创建者Jakub Nesetril的采访 API蓝图）。

去年，RAML 1.0终于发布，围绕处理越来越多的API并面临API样式一致性，重用和协作等挑战的API团队的建模需求带来了大量创新。至此，很明显，虽然OAS率先成为标准的核心API合同规范，但API Blueprint已围绕API生命周期的其他方面（例如API文档）开发了引人注目的创新，而RAML在API建模方面也做了同样的事情。

与其在正在进行的三项努力之间保持直接竞争，不如希望其中一项会取胜并取代另外两项，而是一条必经之路，也是可能的。我与这个故事的主要参与者以及建立支持OAS和RAML并支持我们的用户的Restlet Studio之类的工具非常接近，我意识到理想的做法是让Apiary和MuleSoft加入Open API Initiative，并一步一步地贡献自己的力量。这三个规范的趋同，而不一定是合并。在API测试方面，也有类似的标准化需求，但是除了HAR（HTTP ARchive）格式外，只有专有格式可用，例如Postman Collections或JMeter Scripts。