BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The HTTP API Space is Consolidating around OAS

The HTTP API Space is Consolidating around OAS

MuleSoft has become a member of OAI and released the API Modeling Framework that understands both RAML and OAS. Restlet Studio now supports RAML.

Currently, there are three main competing HTTP API specifications: Open API Specification (OAS) by Open API Initiative (OAI) – based on Swagger, RAML with MuleSoft as a main contributor, and API Blueprint backed by Apiary which was bought by Oracle this year. While all three specifications have their own merits and tools built around, OAS has attracted the main support from the community after Swagger was entrusted to the Linux Foundation in 2015. OAS was supported from day one by 3Scale, Apigee, Google, IBM, Microsoft, and PayPal, among others.

It is not clear how the HTTP API space will evolve in the future, but there are some interesting proceedings taking place lately. One of them is the recent announcement from MuleSoft to join the OAI. Uri Sarid, the CTO of MuleSoft and the creator of RAML, has started to participate in the OAI Technical Developer Community and considers that "everyone should support a common format that can at least describe the service model of an API" and that format should be "the one most commonly-adopted today: the OpenAPI Specification."

Since MuleSoft is still "committed to supporting the RAML initiative and investing in and broadening its ecosystem," we can conclude that Sarid’s presence on OAI TC is meant to push OAS development into adopting some of the features now supported by RAML: API modeling, support for modules, and the separation of concerns of an API contract. It remains to be seen how much the OAI TC will borrow from RAML. To this end. MuleSoft has open sourced the API Modeling Framework, a way of interacting with APIs and modeling them, then generating RAML or OAS documents. Practically, one could take an API defined with RAML, parse it and generate the corresponding OAS file.

While MuleSoft’s API Modeling Framework is "alpha" and "experimental", Restlet, one of the initial members of OAI and recently a member of RAML Workgroup, has released a new version of their Studio supporting both OAS and RAML. Jerome Louvel, founder of Restlet, has expressed his take on RAML’s influence on OAS:

Instead of keeping direct competition between the three efforts going on, hoping that one would win and replace the two others, a better path became necessary and possible. Being close to the main actors of this story and building tools such as Restlet Studio that support both OAS and RAML and listening to our users, I realized that the ideal would be to have Apiary and MuleSoft join the Open API Initiative and contribute step by step to the convergence, not necessarily the merging, of the three specifications…

On top of the upcoming OAS 3.0 release, I envision a future release of RAML that would extend the OAS specification to capture API modelling information present in RAML 1.0 today and more. It would keep OAS core simple and focused, while enabling better interoperability between API modelling tools and help protect the investment of API teams during design-time. As Restlet is part of both the OAI as a founding member, and the RAML workgroup since last week, I’m looking forward to directly contributing to such efforts.

And indeed, Apiary joined OAI last year and added support for Swagger to their tools. It looks like the HTTP API space is consolidating around OAS. This means one API specification for the future, making it easier for users to create interoperable APIs. It remains to be seen how much RAML and API Blueprint will influence OAS.

Rate this Article

Adoption
Style

BT