David O’Neill, CEO & Co-founder, API metrics
When it comes to API performance, how do you know that the results you are seeing, as a developer or manager, are the same results that your customers are getting as they use the application? There have been many improvements in end-user experience, over the past five years, which consumers have very little tolerance for, like latency or query time-outs. The explosive growth of public and private APIs, driven by the popularity of mobile applications and the Internet of Things, has created all kinds of new problems though it solved plenty of old ones. My business partner and I first came to the U.S. as suppliers for Microsoft. We kept finding ourselves in situations where Microsoft users would complain that a particular app was sluggish and the internal teams would keep on insisting that everything was working normally but it was only on their side. As we tried to dig deeper to find the source of this problem, we realized that the health and responsiveness of the APIs used were being overlooked throughout the process.
API testing is a key part of the development process, but if its efforts stop after the product is released, or if it isn’t done from the perspective of the end user, developers will overlook a lot of potentially disastrous problems. Testing from inside your firewall can give a completely different picture of API health than testing from a data center halfway around the world. This can unearth many errors that go unnoticed by the development team. Even if your product performs perfectly at launch, unexpected issues with your APIs may emerge once your app is pushed into the wild. Today, if you don’t continue to monitor the health of your APIs proactively, you will not notice problems such as latency until your social media feed and help desk are overrun with angry users. That isn’t just embarrassing, it’s damaging to your brand and to your business. Here are several examples of unexpected problems that can occur if you don’t give your APIs the attention they deserve.
Cross-cloud Issues
Latency actually varies a considerable amount between different cross-cloud API calls. Calling one cloud provider from an app hosted by the same provider does not always have the lowest latency. A good example of this came out of our latest API performance study–we found the best results when calling APIs hosted on Azure from Amazon Web Services. If you are building an API and you know most of your users will be hosted on a certain cloud service, it’s wise to research the best platform to host your service or you may be setting yourself up for future problems.
Location
Where are your users? The physical location of servers makes a difference in the latency of API calls. Users halfway around the world might be getting slow service, but you’ll never know if you’re always hitting your server from inside the office. Simulating API calls from real-life locations can solve this problem, or at least let you know that the problem exists.
The third-party APIs are Slow
If you’re using APIs from Facebook, LinkedIn, GitHub, Docker, or any of the thousands of other public APIs out there, their poor performance could be affecting the performance of your own app or service. Customers won’t know the difference, so you’ll end up getting the blame for something that isn’t directly your fault. Your IT people need to be able to tell if the problem is coming from Facebook’s API or if it’s an issue with your own software.
DNS Problems
Cloud service DNS look-up impacts API performance significantly. This depends on many factors such as cache management, DNS location, and cloud service provider. Without testing, you won’t know if DNS problems are affecting your APIs or how to solve them.
Security Tokens
Your API testing tools may not be set up to handle secure API transactions. APIs for mobile banking and other sensitive information have security tokens in place (such as OAuth or OAuth 2.0) that refresh at regular intervals. You’ll run into problems monitoring secure API calls if your testing tools aren’t equipped to handle them.
Blend of Protocols
REST might be the current king of mobile APIs, but plenty of older SOAP protocols are still in use within company back ends. If your business is using more than one API protocol, you’ll need a testing solution that supports all of them.
A P I Gateway: Is your gateway introducing lag? If your IT team is testing–but from inside your firewall – then they may be blind to this problem.
Your Results are too Complicated
Can non-experts use your data? If your business is built around a software service or app, non-technical employees may need quick access to information about your APIs. Can a customer service rep or salesperson look at your test results and tell if things are working or not?
There are many other unexpected API issues you may encounter, such as API calls failing and returning the wrong error message, or your developers accidentally changing part of an internal API and causing mystery errors. All are solvable, but the first and most important step is pinpointing the problem before your users find it. API testing should continue throughout the entire product lifecycle and for best results it needs to be based on an end-user perspective. With a robust set of repeatable API tests from inside and outside your firewall and replicating results from a variety of locations and cloud service providers that provide clear, easy-to-understand data, you’ll be well prepared to tackle all of these issues and more.
