Posted on 01-16-2014
I’m spending the next couple weeks going through each of the leading API design approaches: API Blueprint, RAML and Swagger. Even though I still personally use Swagger in my own work, I’m pushing myself to learn API Blueprint and RAML to better understand the landscape, as well as the pros and cons of each approach.
If you aren’t familiar with this emerging trends in API design, they are approaches to defining your APIs either using JSON or a markdown language, which allows you to quantify and describe the API interfaces and underlying data models in a way that allows you to communicate with others, generate mock or production APIs, interactive documentation, code samples and potentially other tooling that will help you be successful in your API initiatives.
While there are other approaches, I’m focusing on what I consider to be the three leading approaches right now:
- API Blueprint - Using API Blueprint gives you awesome tools for your whole API lifecycle. Use it to discuss your API with others. Generate documentation automatically. Or a test suite
- RAML - RESTful API Modeling Language (RAML) is a simple and succinct way of describing practically-RESTful APIs. It encourages reuse, enables discovery and pattern-sharing, and aims for merit-based emergence of best practices
- Swagger - Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services. The overarching goal of Swagger is to enable client and documentation systems to update at the same pace as the server
I don’t feel there is a right or wrong answer to which API design provider you choose. What I want to understand is the nuances of each, how they help us define our APIs, what tooling is available for each, and what does the overall community of developers look like for each.
I’m very interested in the potential of these API design approaches empowering not just developers, but reaching a larger business audience with API design tooling and a language to articulate, and communicate around API resources. APIs are a very intangible thing, and anything we can do to make them easier to describe is a big deal.
Over the next couple weeks I will be playing with several basic “hello world” examples with API Blueprint, RAML and Swagger to help demonstrate what is possible. Then I hope to get more advanced, and understand the tooling available to me from each platform. I’ll even look through their roadmaps and talk to their creators to see what the future holds when it comes to API design.
Which approach are you using to define your APIs?
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- 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 18Fs, 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
- Look At Existing APIs In The Space Before Designing Your Own
- Libraries Hacked: UK Library API, Data And Technology Hacks
- Financial Data Aggregator Yodlee Looking For A Director of Developer Evangelism
- AutoDevBot Open Sources Their API Monitor
- Low Hanging Fruit For API Discovery In The Federal Government
- Looking At 77 Federal Government API Developer Portals And 190 APIs
- Applying APIs.json To API Discovery In The Federal Government
- The Power In API Discovery For APIs.json Will Be In The API URL Type