Apiary Releases ‘World’s First’ Automated API CI Testing Service
Reflecting the continued maturing of the API economy, API design tooling stack Apiary has introduced the “world’s first” continuous integration API testing service.
The launch was made after user testing and feedback was received on an open source version of the project, named Dredd, after the dystopian police cop from UK comic 2000AD.
“We are seeing an incredible surge across whole industries,” says Jakub Nesetril, CEO and founder of Apiary. “Five years ago, APIs were built as a side product but today we are seeing incredible collaboration within the enterprise, with everyone converging on a design-first approach.”
Nesetril says he is seeing a sea-change in the way enterprise teams are coming together around APIs, with many moving to the sort of model spelt out by Accenture’s Teresa Tung in the Industrial API model.
“I just came back from a meeting with a brand enterprise and we had 50 enterprise architects and other decision makers, all sitting around the table talking about driving consistency to make sure that everything can be built quickly, that standards are met internally: this is what it means for them to be secure,” Nesetril says.
Industrial API Model
This reflects Tung’s model which found that in the enterprise, API maturity often begins with an individual use case for an application or workflow which leads to the creation of a specific API within that use case department. But then, over the next six months or so, other parts of the enterprise take similar approaches to pilot projects quickly leading to a chaotic catalog of APIs that have been use-case built without a long term, industrial mindset for the agency’s broader needs. Accenture’s Industrial API model suggests that after the first couple of use cases demonstrate the power and efficacy of APIs, that future design be built using internal standards so that there is common nomenclature and endpoint descriptions for APIs, and that opening data sources and functionality via API is thought of in terms of wider potential uses rather than just a single use case.
Apiary — and its Apiary for Enterprise product in particular — are built specifically around the “API Blueprint” API description format with the aim of making that industrial maturity possible.
The product is gaining significant traction, and Nesetril says much of this is in enterprises who are using Apiary to describe and build internal APIs, hence his figure of 160,000 APIs built using the API Blueprint language. While much of this may be internal APIs, there are some data points that suggest API Blueprint is a popular description format amongst developers.
Traction Amongst API Description Languages
Amongst the three most well-known description formats — API Blueprint, Swagger and RAML — API Blueprint is leading in terms of GitHub users (whether measured by those who have starred the repo, forked it, or contributed to the open source projects). StackOverflow gives a slightly less clear picture: more developers ask questions about Swagger, but API Blueprint comes second with RAML trailing.
(As a side note, for those looking for a way to convert between API description languages, Bobby Brennan has recently released a JavaScript package that can convert between the three formats.)
If many of Apiary’s customers are using the API design tool internally, the addition of the testing service is a crucial new offering that can help ensure an agile, less complex API data model environment.
An Automated CI Tool
“This has never been done in the API space in a way that is fully automated,” says Nesetril. “It completes the lifecycle for us.”
Nesetril is quick to point out that the testing service isn’t a competitor to external API ecosystem services like Runscope, which is focused on production monitoring of APIs. Instead, the testing service is aimed at automating continuous integration processes during development.
“Apiary — being an API design platform — has always been able to run tests locally whenever users hit the save button, to make sure that APIs are being built to specification, that developers haven’t broken anything.
“The new tool allows architects to keep API design consistent across the board. It also helps product managers who are responsible for delivering the products: that there are no errors, that can automatically check the progress of how APIs are being built in the company.”
Nesetril explains that the new testing service enables users to test API specifications against the backend implementation. Developers can also test from their local dev environment as well as from within a Continuous Integration (CI) testing framework. Before the introduction of the service, developers would have to use command line tools to test manually, with “at least one line of code for each key.”
“So this testing service changes things dramatically when you look internally: here, APIs can drive standardization within the company. That’s where this testing becomes really important. With the rise of microservices, you are suddenly seeing companies having hundreds of APIs. So how much software errors cost, gains from developer productivity … we are seeing a 10x boost from developer continuous integration approaches.”
Nesetril says the new tooling is completely compatible with Jenkins, and “all the CI tools out there (both on premises and in the cloud).”
Learning from Dredd
Phil Sturgeon is a developer with carpooling service Ride, and author of “Build APIs You Won’t Hate.” He has been using the Dredd open source project to integrate API testing into his continuous integration workflow.
“This is less about design standards — we are not using it to enforce consistent design. In our team, we have four or five people so we think we can manage in other ways.
“Where we see a huge benefit is in making sure documentation is exactly correct. Often, people may have added new fields but the frontend clients don’t know that existed or it wasn’t added to the documentation. In other situations, a feature might have been added to the documentation but then the development means we altered something and then the documentation doesn’t match what we ended up building.”
Sturgeon — who also uses Apiary’s full API design product — says that while Apiary doesn’t enforce a documentation-first design approach, it does work well within that development culture.
“In my book on building APIs, documentation is chapter 11 and it really should be chapter one. In the past, the way I did it was to use the Postman client and use Postman as documentation so the idea of building the documentation came after when we build. Now, if we have a new endpoint, then we do the documentation and make it available to everyone. So then the entire team can address it and could say that wouldn’t work, can you do this instead … Then we mock up that endpoint and allow everyone to interact with it. People across the organization can comment and their comments will be merged by the testing tool like Dredd, before you make the features and as you make the features.”
It is an approach that other tech companies are seeing as an important way to ensure greater internal collaboration and communication. Karen Cohen, SDK Product Manager at website maker Wix made a similar comment at the API Strategy and Practice Conference in Berlin earlier this year.
“For a long time, we didn’t do anything except the final documentation or the final product,” Cohen shared. “Now we are at a point where when we start a development project, we write a technical spec and share that through Google Docs so that everyone can comment on it.”
Apiary’s new testing service is aiming to take that sort of culture, mature it and automate it.
Sturgeon says that some cumbersome tasks with Dredd have now been addressed — originally users would need to import their data, spin up a server, then shut it down after the testing. Features to automate those processes were added to a YAML file which have now been implemented as part of the product development and official release.
$6.8 Million in Series A Funding
The launch of the testing service within the Apiary product comes alongside the startup’s announcement of $6.8 million in Series A funding, which Nesetril says is the largest Series A amount given to a Czech Republic startup. According to Pavel Curda who writes for EU Startups, Apiary is one of five Czech startups to watch, all hoping to follow in Czech-tech leader Good Data’s footsteps, which according to Owler has raised $96.7 million to date. Apiary may be on a solid track: their series A funding was $0.3 million higher than GoodData’s $6.5 million Series A.
Feature image: “20140905-AMS-LSC-0333” by U.S. Department of Agriculture. Licensed under CC BY 2.0.
