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
- My Discussion Today With 6 Hypermedia Leaders At API-Craft in Detroit
- Getting To Know Jørn Wildt For The API Craft 2014 Detroit Hypermedia Panel
- Hypermedia Feels Like We Are Still Learning To Communicate With APIs
- Getting To Know Markus Lanthaler For The API Craft 2014 Detroit Hypermedia Panel
- Getting To Know Kevin Swiber For The API Craft 2014 Detroit Hypermedia Panel
- Getting To Know Steve Klabnik For The API Craft 2014 Detroit Hypermedia Panel
- New Indix API KickStart Program Reduces Costs For Developers
- Getting To Know Mike Kelly For The API Craft 2014 Detroit Hypermedia Panel
- A Shared, Distributed Experience(Metrics) Layer For The API Driven Application Stack
- Showcasing Your API Integrations With Other Platforms
- Increasing The Focus On APIs In Higher Education Is Important
- Getting To Know Mike Amundsen For The API Craft 2014 Detroit Hypermedia Panel
- The New StrongLoop API Server Provides A Look At Future Of API Deployment
- Models For API Driven Startups Built Around Public Data
- Will You Add Me To API Evangelist And How To Spot The Cool Kids
- When I Remix APIs Using Swagger How Do I Deal With Authentication Across Multiple APIs
- It Takes A Team Of Evangelists To Raise An API
- Support For Only Two Creative Commons Licenses In The API Commons
- Machine Readable Terms of Service Didn't Read Applied To APIs Via APIs.json
- API Deployment For Non-Developers Using Zapier, Google Docs, and APISpark
- State of Hypermedia Today @ API Craft In Detroit
- Need A Formal API Standard For Your Government Agency? Fork 18F's, And Make It Your Own!
- CORS Makes Your API Portable And Remix-able
- Chief Data Officer Needs To Make The Department Of Commerce Developer Portal The Center Of API Economy
- An API Definition As The Truth In The API Contract