API Tooling Companies: We Are Watching You.

2015 has seen the rise of a range of API tools aimed at helping API developers to better manage the delivery and performance of APIs in production and consumption environments.

API Science, Runscope, SmartBear, 3scale’s APITools, API Changelog, LoadImpact, APIMATIC, and Parasoft all offer tools aimed at helping make sure API delivery and usage doesn’t falter.

But for these tools to foster traction amongst the API community, they need to be able to be easily inserted into an API developer’s workflow.

What developers are needing is a way to automate when these API tools are used. Bruno Pedro from API Changelog discussed some of these needs in his talk at APIdays Mediterranea earlier this year.

Bruno Pedro’s API Days Mediterranea presentation in three slides: from How To Automate API Discovery

He mapped out an automated future where an application or business process might get to a point in the value chain where making an API call is needed to get some functionality (to assess for fraud, to get weather data, to check the balance of an account, to store some data, or a million other things). But what Pedro was imagining was what happens when our processes are automated enough that before they make that API call, they might first check what APIs are available that could perform that functionality, then compare the API terms of service or the pricing policy or the computational accuracy. Based on this assessment, the process would then call the best API for that need and continue along the value chain, all completely optimized and automated.

We are already seeing the emergence of Pedro’s vision in the API development and production value chain. It is similar to what we see in the container space. In container architecture, distributed applications might use service discovery and automation tools to identify what functionalities are available and when they are needed, and then spin up instances as needed, retiring them to reduce costs when the needs lessen.

API developers are learning from that approach and looking for ways to automate stages in the API development or consumption process when you might:

  • call on a testing tool
  • monitor when API terms of use change
  • autogenerate documentation or SDKs
  • send an alert when load performance drops, or
  • respond when an endpoint returns an error.

To create this type of automated workflow you need a way to describe the API to all the testing tools, performance monitoring tools, changelogs, pricing assessment tools, API catalogs and the rest.

That is where API description formats become increasingly important. If an API has a description file written in Swagger, RAML, API Blueprint, or a Postman file, then you could use that file as the common way to automate passing the API on to various workflow tasks, in the same way that in a containerized workflow, the deployment environment can automatically test an application’s merged updates and if it passes the test, spin up a new version, add it to the registry and push it to production.

As API Architect at The New York Times, Scott Feinberg has pointed out, the API tooling industry has already caught on.

The third quarter of 2015 saw an increasing number of API tools offering to automate their service functionalities if an API simply provides a description file.

There are also a few new API description transformation tools emerging that can automatically turn a file from one API description format into another. API Transformer and Lucybot — released during 2015 — are both automatic converters that can change an API description file from one type into another.

Now, as the final quarter of 2015 gets underway, we are seeing the rapid availability of a new set of workspace environments aimed at helping API developers and consumers stitch together those processes in a unified platform. Restlet, Apiary, SwaggerHub, RepreZen, API Garage and Postman Sync are all beginning to announce themselves as seamless platforms aimed at automating development, testing and performance monitoring tasks directly from an API description file. The best of these are looking to integrate to ecosystem tools that already exist to perform such specific tasks.

Again, a lesson from the container ecosystem is valuable here. Engineers, for example, can make use of Docker’s orchestration tools to manage server and cluster usage for their distributed applications. Or they can use other ecosystem tools not made by Docker to perform these orchestration tasks.

With this new breed of workspace environments aimed at helping automate the API lifecycle, the temptation is there for these emerging platforms to create a closed ecosystem.

Competition will be fierce from the start: providing automated tooling is one of the biggest needs today. API developers are facing increased complexity from the maturing of the space, so tools that help move through the API development, production and consumption lifecycles will be in growing demand. Each platform offering will be vying to build out their own community of loyal developers.

Some may be keen to try and build a closed ecosystem where you are locked in to working within their own set of tools or with their own chosen partners. But the best of this new breed of services will be looking to meet developers where they are and will allow developers to orchestrate their own automated value chain using whatever description format they want and swapping out whichever testing or functional tool they want to use along the way.

Already there are signs that some players may be reluctant to allow that. The developers right to automate is not yet a given in the API economy.

The good news is that all of the API description formats are currently open source (under MIT or Apache 2 licenses). But also, each API description format is being led by a major competitive player in the space who may look for opportunities to close — or at least filter — the ecosystem.

Developers will be watching carefully to see if that happens and won’t hesitate to fork the initial description language and create a new product offering that stays true to what the developer believes in the open source project. Again looking at the container space, we can see that has already happened too. CoreOS sprung up out of Docker as one group of developers felt that they could head in a better operating system direction than the one the container platform was pursuing.

Already, we are hearing from the APIdays community that developers are watching product roadmaps carefully as API tools mature and the competition environment heats up. The take home news for API tooling and workspace platforms in particular is this: we are watching you.

Show your support

Clapping shows how much you appreciated APIdays’s story.