Your API’s Need for Speed

[This article was written by Paul Bruce.]

APIs aren’t just about what content they deliver; they are also about how well they deliver that content.

With the API Economy on the verge of outright explosion in 2015 – as if it hasn’t been exponentially growing year over year since 2005 – it’s no surprise that even institutions that are traditionally slow to change (like governments) are quickly realizing that they have some serious catching up to do.

Cutting edge web companies that premise their designs with good practices like team methodologies, continuous delivery, and data-driven strategic decision making, already realize the benefits of the Programmable Web and know the payoffs of having API-centric data distribution.

The very nature of an API implies that at some point, multiple consumers need to access the data and business logic behind the service. APIs are an admittance of concurrency in data delivery, from the front-facing services to the back-end data stores, throughout the middle mile, and all the way from the cloud down to the client.

So why aren’t more business load testing their APIs, especially when it’s getting easier to do so?

Well, functional tests are an easy way to say that the developer(s) reached completion of a feature or fix, and then people have to move on. Tools like SoapUI are making it increasingly easier to test something before marking it as complete. However, they generally don’t address topics like concurrency or require you to know things like the virtues of percentiles and medians over averages.

Load tests, on the other hand, require much of the technical complexity of functional tests and introduce a few barriers to success of their own, the least of which is software cost. You typically need a staging environment (roughly equivalent to production), which is getting easier to spin up in the cloud, but only if that applies to you. Still harder is the knowledge and experience you need to build simulations that accurately approximate user behavior and that are scalable. In other words, knowledgeable enough to translate load test results into actionable changes to improve performance. It’s not easy because the problem is hard.

But again, why would you bother building an API if you’re not going to make sure it satisfies?

Without load testing, you won’t know what level of demand you can satisfy on that “good day” where people love your service and want more of it. On a “bad day,” you may find that there are problems so deeply rooted in your architecture or infrastructure that short-term resolution or even mitigation is impossible.

In other words, API quality is more than function and form, it’s equally about performance.

Testing the function of your API using SoapUI is a great and necessary start to implementing automated quality assurance over your services. The next step is to load test your API, and SmartBear has purposely streamlined the process of taking your functional tests from SoapUI and using them as load tests in LoadUI. SmartBear knows that the less time you spend twiddling with tests, the more time you can spend making informed decisions about how your API works and performs.