Posted on 06-28-2014
We are still in the infancy of the API economy, and now with barely 14 years of evolving web API design, we are only just now developing the languages we will need to communicate around APIs throughout their lifecycle, from the first mock of the API resource, to monitoring of a production API in the wild, or making available to a new breed of API search engines.
There has long been standards for describing APIs, such as WSDL for SOAP, and WADL for web APIs, but these formats would never actually enable the meaningful interactions around APIs that it would take to find widespread adoption. WSDL was too programmatic, and heavy handed, while WADL never possessed the incentives for API providers to take the time to define their APIs using the heavy XML format.
It wasn't until early 2011, we would see the first signs of a meaningful language for defining web APIs, that would enable us to have productive conversations, and take action around our API designs. In February 2011, online word meaning and definition site Wordnik, launched a new API developer portal, complete with a new way to document APIs, that was interactive, and allowed developers to make live API calls, while learning about an API. In an effort to keep their API documentation up to date, Wordnik has also established a new way to not just document and communicate with an API, but allow us to actually have a shared conversation about the actual design of the API itself.
Later on that year, API management provider Mashery emulated Wordnik's approach, and launched their I/O Docs. Immediately after, in August 2011, Wordnik formally launched their approach to defining APIs, generate interactive documentation, and server or client side code—which they called Swagger. Over the next two years the Swagger ecosystem would grow and evolve, producing new versions, tooling, and implementations of both private and public API implementations.
During this time, the concept of API design would expand, with tech giants like Google establishing their own approach, which they called Google Discovery, and we would see a new breed of API design service providers emerge with Apiary.io. By March 2013, Apiary had launched their own API definition format called API Blueprint, which allowed API providers to define an API using markdown, and iterate on the design using Apiary.io services. Apiary moved the incentives for defining APIs in a machine readable format earlier on in the lifecycle. Now we didn't just generate machine readable definitions to deploy server code, or generate interactive docs and client side code, we would do it before we actually deployed the API, allowing us to mock our API designs, and collaborate around designing the actual API prior to deployment.
Then by the end of 2013, we'd see another API definition language emerge, this time from enterprise technology provider Mulesoft, called RAML. This new approach to defining APIs, would use YAML to produce a machine readable, yet human friendly way to describe APIs. Now we had four new ways to describe our APIs, and as we push into 2014, we have a wealth of tooling, services, and a selection of maturing API design editors to choose from when planning and designing our APIs.
I feel like we are just moving from infancy, into the toddler phase of communicating throughout the web API lifecycle. We now have several languages to choose from, we just have to work hard to educate people that they exist, help them become fluent, and expand the incentives for generating machine readable definitions for our APIs. In the next year, I predict we will see an increased adoption of the leading API definition formats, new tooling and services that helps us design, deploy, manage, monetize, evangelize and integrate with APIs that are driving the API, and app economy--driven from a central, machine readable API definition.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Beyond Public APIs In Government: Internal Access to Resources
- Can You Show Me The ROI On All Of This API Stuff Before We Commit
- In The Future APIs Will Be Default For All Cities
- No Public APIs Are Not Going Away Just Cause A Few BigCos Fumble At It
- Internal API Search Engine For Everyone At Your Company (Not Just Developers)
- If You Need Assistance With Your Healthcare API Strategy I Have The Person
- Explaining APIs To Senior Leadership: Access To Company Resources Without The IT Hassle
- A Conversation With @ijroth, @dorkitude, @antonyfalco, and @medjawii In The Next Generation API Stack Panel @APIStrat
- API Evangelist Thoughts On The Right To An API Key And Algorithmic Organizing
- Explaining APIs To Your Senior Leadership
- An API Evangelism Strategy To Map The Global Family Tree
- Thank You For Your API Evangelist Blog(s)
- Video From The Hypermedia Panel At API-Craft In Detroit Last Month
- Please Open Source Your API Before Shutting It Down
- Explaining My Work Around APIs In Higher Education To Institutions
- You Can Have An API Just By Choosing Products And Services That Have APIs
- Using Excel As An API Datasource And An API Client For The Masses
- Brewing Up Something Awesome With The Jive Software API
- Relationship Between APIs And Containers
- Real-time and Visualizations Will Be Key in Financial API Deployments
- Notification Focused Startups Within Leading API Ecosystems
- APIs That Do One Thing And Do It Well Like ZipLocate
- Which API Do I Need?
- The Expanding API Conference Landscape
- Ocotoparts Open Source Google Spreadsheet