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?
