Share & Support Your API
The great thing about RAML is that it not only lets you design your API, but actually defines your API. This means that this very same RAML spec can be used to integrate your API with other systems, and even generate SDKs for today’s most popular languages.
Plus, with the API Notebook you can even offer interactive walk-throughs and sample use-cases for your API, while also letting developers communicate back in a standardized format with your support team - making their job super easy!
Creating code libraries for your RESTful API in Java, .NET, PHP, Ruby, NodeJs, iOS, Windows, Go, and more is as simple as clicking a button!
You’ll find several different community tools available to create these SDKs so that your engineers don’t have to!
This means you can easily created updated code libraries every time you update your API with no effort on your engineering teams part - letting them focus their time on more important things - like new features!
Third Party Tooling
Just as you can create SDKs with RAML, many companies have built-in support letting you pull in your API’s resources, methods, and properties automatically!
For example, Oracle and MuleSoft offer enterprise tools that let you easily connect to any API described in RAML just by pasting in the RAML spec URL. No more guesswork, and no more having to manually setup your API calls in these popular tools.
Using simple markdown, you can create unlimited notebooks demonstrating different use cases or examples of how to use your API.
Want to learn more? Just check out some of these sample use cases (and learn more at apinotebook.com):
- Search for cute kittens on Instagram
- Find Your Last Follower on Twitter
- Get a list of your GitHub gists
As you can see, the API Notebook takes all the guesswork out of HOW developers can use your API to accomplish your most popular or important use-cases.
But what makes the API Notebook truly unique is that ANYONE can create their own notebook. Users can easily clone your existing notebooks or create new ones to share their exact use case - and let you immediately see what issue they’re REALLY having.
This means no more digging through proprietary, partial code in order to figure out if the bug is in their code or in your API - but rather knowing immediately if they did something wrong in their process of calling the API, or if there’s a bug on your part.
This also lets your users debug their own calls to make sure they’re doing things right!