Digital businesses are making a radical change in the way they build and deliver software. Gone are the days of apps that rely solely on in-house tools. Rather, today’s apps are increasingly dependent on external APIs and third-party app providers (which, in turn, are reliant on other APIs and apps).
While this type of modularity allows for product flexibility and rapid development, it can be difficult to address any issues that arise. If even one component of this chain breaks, it can have a domino-effect on its dependents, whereas a similar failure in the closed systems of yesterday would have just led to an isolated incident.
This challenge is magnified by a microservices approach where developers can deploy a single service, without relying on the rest of the application’s components to be completed. Whereas the traditionally designed components tend to be larger and encompass many functions within a single layer, the discreteness of microservices make them more nimble and able to be scaled quickly as load demands increase. Without the right tools, this can make troubleshooting extremely difficult as microservices exponentially increases the points of failures.
As such, if your product relies on external APIs, it is important for you to test and monitor for more than just availability. You will also need to keep tabs on performance, data validation and processes, feature changes, and security.
Why It’s Important to Test API Performance
API failures that disrupt the performance or user experience on your site reflects poorly on your company–even if the disruption is caused by a third-party provider. And, depending on how critical that API is to a transaction process, this failure could impact your bottom line right away.
For example, if a key component of the checkout process on your website is a location-based search and you rely on a third-party API to provide the search by location, when that API doesn’t work correctly then your potential customers cannot checkout successfully.
Parkmobile relies on APIs to show customers available parking locations.
Or imagine that you developed an application that requires authentication from a social media platform. If the API for that social media platform goes down, your users might not be able to log into your system.
As a developer or a site owner, you may decide that the benefit of relying on the third-party service outweighs the risk of these types of failures. To accurately assess the risk and have visibility into the impact of these services over time, it’s crucial that you monitor the part of your site’s user flow that relies on an API.
You could monitor this type of user flow or transaction with a multi-step user flow in a browser. However, this isn’t sufficient when a transaction consists of a series of API requests with various assertions based on different qualitative components of the API response. On the other hand, an API monitoring product that breaks a user flow into its various components gives you specific insight into what went wrong by just looking at the step the test failed on.
When testing APIs, you should consider both APIs that your website or native application relies on for critical data or processes, including those that you don’t own and APIs you manage that customers, end users, or developers rely on for data or processes.
What to test for
At the most basic level, API testing and monitoring checks to see if the resource is available (and therefore responding to calls) or not. However, with the increasing levels of inter-dependence of apps on other apps and services, you should strongly consider testing the availability of the resources your APIs rely on as well. Receiving notifications about any possible breaks in the chain of dependence allows you to act appropriately to ensure that your site or app stays online, even if others do not.
How quickly is the API returning responses? By testing for response time you can determine if responses are worse in production compared to pre-production. Additionally, with monitoring you can also determine if response time degrading over time.
Your API may be available and responding to requests, but what if it sends back incorrect data or is not formatted in a way you anticipate? This is why you should test regularly to ensure that your systems are getting what they need to carry out tasks. Learn more about API request headers.
Additionally, you should check to see if any multi-step processes you carry out once you’ve received the response also work as expected. Can you cache data from calls to save on repeat calls to the API? Does your authentication work as expected?
Test Integrations with Third Party & Partner APIs
As we mentioned before, apps and services oftentimes rely both on managed and third party APIs, and frequently users cannot tell the difference between the two. Ensure that your monitoring solution gives you visibility into the performance of third party and partner in addition to those you manage. By doing so you will not only be able to hold partners accountable, but also know who to contact should any issues arise.
Test for Feature Changes
When you have functionality that depends on the performance of an external service, you’ll want to ensure that your app remains compatible with the service. Regardless of whether the changes are a result of new releases or bug fixes, your base code may not work with the service from generation to generation.
Certainly, testing in production is important, but it is better to get ahead of any bugs before they are deployed. As such, if you host an API that other people rely on, be sure to actively monitor that API in both pre-production and production environments.
Whether you are seeking to keep tabs on your own APIs or see the impact of external services that you rely on, it’s important to test APIs for availability, functionality, speed, and performance. If you know you have an API that’s been unreliable in the past and you’re not actively monitoring that API, start the conversation with your team and develop a plan to begin monitoring that API today.
What is Splunk?
This posting is my own and does not necessarily represent Splunk's position, strategies, or opinion.