29 November, 2018
APIs open up a world of possibilities for developers all over the world, making it possible to create third-party software. As such they are the foundation of their creativity and the way they work has high impact on of software development efficiency and app performance. On the down side, they require efficient cooperation, both in short- and long-term, between backend and frontend developers, testers as well as other project members. Oracle’s Apiary is one of the most successful attempts at making this cooperation smoother, speeding up and simplifying development in the process. Say “hi” to the Apiary API documentation tool with our quick tutorial.
There are few tools on the market as complex and advanced as Apiary. It’s an API documentation tool (when really, it’s much more than that), which allows you to quickly design an API and share it with whom it might concern using a mock server provided by Oracle. It has a wealth of features, each of which can be very useful on its own. But it shines its brightest when we use its full potential.
When we do we can quickly create and mock our APIs, share them with clients and developers, automize the process of creating highly interactive and very beautiful documentations and much more. With this article, you will be ablo to unleash the potentian of theAPIARY API documentation tool as well. So let’s cut to the chase.
APIARY – how does it work?
At Apiary’s heart is API Blueprint – a high-level description language, which makes designing APIs a breeze. Once our list of requirements is ready, the system will verify our syntax and subsequently launch a mock server, which will respond to our requests. At this point, frontend developers can already start working with it. But our journey with Apiary is only beginning. After all, our API description is a contract that all backend and frontend devs need to adhere to, so we need to commit it to our repository. Apiary’s deep GitHub integration makes it a one-step process. What’s more, thanks to integration with Dredd – a testing framework – backend services will be able to automatically generate tests. All that’s left to do is write code that will pass them all.
Cool. But in order to understand why all this is so useful, we need to take a step back and answer another question.
See also: Introducing a technical writer
Why do we need contracts and mock servers?
Frontend and backend developers can’t always work simultaneously – timing is very important. For example, a frontend dev can’t do its job without mocking endpoints first unless all backend job is done. As a result, one task can often span two, three, or even four sprints. if we could somehow make it so that frontend and backend are entirely independent from each other, development would be much faster. Let’s see how it can be done without having to create an all full-stack team.
Once we commit the contract to our repository, we can create our definition of done, since we now know what and where should be achieved. When the contract is verified, Apiary launches a mock server, which means that a frontend dev can start their work. Backend work is easier as well – Apiary can use the contract to generate automated tests for use in Dredd. This framework can help us test the implementation of an API. It’s not quite as sophisticated as Behat, but more than sufficient to generate basic tests for our app to comply with.
And what if a developer breaks the contract? Since we’re using automated tests, we will be informed about it instantly.
Creating an API description with Apiary documentation tool
Making an API description with API Blueprint is quite straightforward. The language itself (Oracle’s own creation) has a low barrier to entry. Bundled with our first project is an example description, which we can freely use. Once you master Apiary, you can try Swagger – a more complex and capable API description language. Unless we need modelling or imports, API Blueprint will suffice.
As you can see, the syntax is reminiscent of Markdown. Above, you can see the description of an /elements endpoint, which responds to GET requests. The endpoint will return a collection, which here includes just one object. Apiary will render the endpoint to the right.
What can we find under List All Elements? Could it be that Apiary has something more in store for use?
As you can see, the mock server returned just what we requested. The frontend dev has all they need now. What about the backend? We’ll soon get to that. But first…
Thanks to the convenient API Inspector, we can see exactly who used our endpoints and what kind of requests were made. This is how the inspector tab looks like:
This feature is very useful for frontend developers – if their requests do not comply with the contract, they will know that immediately.
OK. At this point we can rest assured that Apiary will be of use for our frontend friends. What about backend? There are plenty utilities for them as well, but the one that stands out the most is….
Dredd – simple API testing framework
Dredd is another handy API solution from Oracle. It’s an API testing tool. Does that mean that it is yet another Behat? Of course not. Had it not provided anything new, it wouldn’t have been made.
When compared to Behat, Dredd does away with a lot of complexity. Its main goal is to extract the definition of endpoints from the Blueprint file and send them over to our (local) backend. Thanks to that, we can quickly ascertain if the data format the endpoints return meets our requirements. How to do that? It’s quite simple. The “tests” tab includes a short tutorial, which guides us through the process of installing an app and creating basic config files:
Open your terminal, use the “dredd” command, sit back and let the magic begin.
Now we can be sure that our endpoints return data properly. Keep in mind, tough, that Dredd does not test the logic of our app. Backend still requires BDD tests.
See also: Software testing trends for 2019
Back to Dredd, when the test is over, we are given an URL that takes us to the results page. Each completed test has its own separate tab in Apiary so that we can get back to them:
Now we know that our script has tested all endpoints, allowing us to mark the job as done (complaint with the contract).
We sure saved a lot of effort and, by extension, time and money!
Apiary’s selling feature – full GitHub integration
Apiary is integrated with GitHub by default. We can instantly create a new branch out of our new API contract, and then git-commit it and send to GitHub. The entire process takes just a few clicks to complete.
- To begin, click the “Push” icon at the top right.
- Enter a commit message.
- The changes are moved to the master branch of our repo.
Unfortunately, the master branch is the only one we can choose in a free version. To push changes to other branches, a paid plan is required. And it may be worthwhile to go for as it gives us big advantage – with that, our endpoints can fully become a part of our project. We will be able to use version control to know exactly who and when modified the contract. Business-wise, it’s a massive benefit.
I think that by now you know just how happy Apiary can make both a dev and your client. Whether you plan on using all or some of its features, you should find it very useful. To give you an idea, in one of the projects I did, we used Apiary to create a mock version of an external (paid) API, using documentation provided by the vendor. Once the project was out of development, switching to the real deal proved amazingly easy.
One of my colleagues created a contract that included over 60 endpoints. With that, it was possible to integrate half a year’s worth of backend and frontend work within 5 days. It’s hard to think of a better recommendation for Apiary than this. What’s more, the entry threshold is low enough that you can start your first project as early as today. And backing from a company as big and trustworthy as Oracle means that your project is certainly in good hands.