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
- Making Sure The Most Important Layers Of API Space Stay Open
- A Common Place To Manage All The API Definitions In My World
- Swagger 2.0 For The Docker API
- On Being An API Broker For Hackathons
- Are You A Hypermedia Pragmatist?
- Do You Know That Hypermedia Is A Better Solution For Discovery Than APIs.json?
- API Service Idea: API Via Excel From Within Corporate Email
- With Number Of APIs Continuing To Grow Account Automation Will Be Key
- History Of APIs: NOAA APIs Have Been RESTful For Over 20 Years
- Understanding More About The Web Communications Platform Respoke