I was on the road last week, so I didn't maintain my usual barrage of API analysis. As I go through my monitoring for the week, I'd say the biggest news of the week was Apiary's support of the OpenAPI Spec. I got a test drive of the support for the API definition format over the holidays, and was impressed with how smoothly Apiary integrated the OpenAPI Spec into their API design, virtualization, and management platform.
Another very interesting dimension of the Apiary release for me, was how they seamlessly integrated the new API definition into their road map. This wasn't a switch to the OpenAPI Spec from API Blueprint, it was about opening up, embracing, and abstracting away of multiple API definition formats across their platform operations. As an API service provider, it is just smart business to support as many possible API definition formats as you possibly can. The 2016 road map for Apiary acknowledges the value of using the OpenAPI Spec, but still reflects the strengths that API Blueprint + MSON bring to the table.
Last September, I walked around San Francisco with Jakub Nesetril (@jakubnesetril), the CEO of Apiary, talking about the need for an open abstraction layer to help us better define our API, across all stops of the API life cycle. This wee's OpenAPI Spec support at Apiary is Jakub's vision playing out, making sure the process of defining your APIs across the design, virtualization, and management areas of your API life cycle is as robust, and agile as it possibly can be. For me, this makes this weeks news much more than about Apiary abstracting away the complexity of switching between leading API definitions, than it is about their support for the OpenAPI Spec.
I had beers with Emmanuel Paraskakis(@manp) and Jakub at the Toronado on Haight Street in San Francisco this week, and had another conversation with them about their abstraction layer, which helps them efficiently switch between using API Blueprint and OpenAPI Spec in Apiary. They expressed interest in exploring the open sourcing of this layer, to help others achieve similar abstraction in their own platforms. During our talk Jakub reiterated his earlier vision of an open abstraction layer, where each API definition provider(OpenAPI Spec, RAML, Postman, APIs.json, etc) can maintain theri own plugins, abstracting away this work for API service providers.
Consider the opportunities when any API service provider in the community, serving any stop along the API life cycle, can seamlessly integrate this abstraction layer into their platform. Where they can work with a single API definition layer, which navigates the differences between each individual API definition, and the owner of each definition has to step up and maintain the individual API definition side of the equation. If you are selling your services to API providers across the sector, you should support as many of the leading API definitions formats as you can, and what Apiary is cooking up, will make this reality much easier to achieve.
