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
- 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
- Andrew Nacin Of WordPress @APIStrat Chicago
- Push Button API Deployment With The Heroku Button
- WordPress Style API Modules For Government
- The Heroku HTTP API Design Guide
- What I Have Been Calling API Trends, Are Slowly Being Baked Into API Operations
- FDA Finding Their API Mojo With A New Drug Label API
- Adding PokitDok To Healthcare Research And The API Stack (Well They Did)
- Why I Am Continuing To Integrate Zapier In My Business Workflow
- Who Is Going To Build The Uber API Platform For The Sharing Economy?
- The API Focused Dev Shop
- Route SMS Messages To Google Spreadsheets Via Twilio API With TwilioSheet