{"API Evangelist"}

What Is At Stake With API Definitions At The Moment

I wrote angrily about Oracle's acquisition of Apiary last week, and this week I find myself deeply considering the API definition landscape, so I wanted to take another look at this event from the 100K view. In 2017, API definitions are touching every aspect of the API lifecycle, from design to deprecation, and are becoming key to defining, automating, and evolving many different industries from cloud computing to human services

I define API definitions as the specifications, schema, and scopes that are being used to map out the world of APIs. Specifications for describing APIs are nothing new, and approaches to defining data schema are well established as well. However by 2012 things were changing and Swagger emerged as an important tool for describing APIs in JSON, then YAML, using JSON Schema to define the underlying data definition. Around the same time, Apiary got to work on their own API Blueprint for describing APIs, and MSON for helping define the data and the relationships in play. Then, not to be left behind, Mulesoft "jumped" into the game with RAML as well--there are others, but this represents the top three.

In 2016 Swagger was put into the Linux Foundation, under the Open API Initiative (OAI) and was reborn as the OpenAPI Spec, something that in 2017 is beginning to bear fruit with version 3.0 of the specification. Adding another dimension to this shift over the last year, we just saw Oracle purchase Apiary, and since Apiary is currently in the OAI, this means that Oracle is now in the OAI. I'm sure it is just a matter of time before Mulesoft also makes the move to join the OAI, but I'm not sure what this would mean for RAML--or what it means for API Blueprint. I do know OpenAPI Spec is the dominate format right now, and OAI is the leading group.

I want to pause for a moment and also point out that Oracle is the company that recently set the precedent that the naming and ordering of our APIs are copyrightable. You know, the naming, ordering, and mapping out of APIs that we are trying to get on the same page within the OAI, with the OpenAPI Spec? Granted, the precedent was set with the Java API, but it won't be long before another company test this theory out on web APIs. With the current views on patenting APIs, I'm guessing that many API providers already see their APIs as something that copyright applies to.

Just as we are all coming together to hammer out a language to describe how we create, manage, and move around the bits that define us as individuals, the companies we operate, our institutions, and even public spaces, the biggest tech companies are positioning for their role at the table. I'm not saying this is good or bad, black or white, I am just pointing out that companies are taking their positions, and that there are some very different opinions on what intellectual property is, and what needs to be openly defined, and licensed so that the web remains interoperable, reusable, and working for everyone equally.

I am mapping out all the APIs that are increasingly defining us as individuals. I am also mapping out the API resources that are increasingly defining our small businesses, enterprises, institutions, and government agencies. I am doing all of this with OpenAPI Spec.   These API definitions will the be used to design, deploy, virtualize, manage, test, monitor, generate SDKs, integrate, and automate almost every aspect of our personal and professional worlds in 2017. The value of these definitions is only going to increase. The importance that these definitions are openly licensed, accessible, shareable, and reusable is only going to increase. We need this API thing to work, and we don't need unhealthy and greedy views on intellectual property jamming up the gears.

I wish I could help folks who view API definitions as yet another intellectual property see that there is more money to be made when these things are left open. In addition to helping folks understand what API definitions are, and the important role they play, I'm going to invest significant resources helping demonstrate how business, institutions, and government can work more smoothly when API definitions are accessible, and openly licensed. I'm optimistic about the OAI and OpenAPI Spec at the moment, but this optimism can't help but feel overshadowed by other movements on the horizon--we'll see how it all goes.