Why API Monitoring Matters

Many of us can now say that our web applications are built on an API foundation, both internally and externally. It’s common to discuss which APIs we need to expose to the outside world in order to drive business and, in some cases, to build APIs into the product roadmap during planning meetings. With so much emphasis on APIs, it’s critical to recognize its inherent power and ensure that appropriate safeguards are in place to protect it.

API Errors Are Frequently The Most Serious Errors

Because a single API can impact so many applications/components, modifying or deprecating it can result in massive failures that you may not be able to forecast, especially if the API is public. Once you’ve made your API available to other developers, either in a controlled manner to trusted partners or publicly to anyone with a developer/production key, you’re responsible for ensuring that nothing interferes with its performance. The quality of the API and its performance is affected by factors such as server load, the amount of data coming down, the level of encryption, and the quality of the controller code among many others. 

Of course, you should test all of this before putting your API into production, but you should also monitor those factors after deployment, just like any other important feature. Problems arise when your customers start banging on it in new and different ways. API monitoring can help with this. The significance of monitoring APIs in production is becoming more apparent as we become more reliant on our own and third-party APIs. Because it can bring down so many other dependent applications, an API failure can be more disastrous than an application failure. The API management platforms are all acknowledging the need for some kind of analytics dashboard that goes beyond just showing usage statistics as time goes on.

Creating API Monitors

A cornerstone of your online quality strategy should be creating monitors for APIs you either produce or consume (or both). One of the last excuses you have for not setting up your first API monitor is that you don’t know what to think about or where to begin – so let’s get you started with some practical advice for setting up your first API monitor.

Tip 1: Re-Use Functional Tests From Development

Reusing functional API tests created during development and testing for monitoring has several advantages if you’re providing your own APIs:

1. Instead of just checking for availability, your API’s “real” functionality will be continuously scrutinized, providing you with a safety net for ongoing deployment practices and infrastructure changes.
2. Because your functional API tests are configured to assert and provide relevant error messages, your API monitors will be able to provide much more detailed error information for root cause analysis than regular availability monitors.
3. Because your functional API monitors simulate expected usage scenarios, their actual structure can inform Ops about how your APIs will be used and assist them in setting up the API infrastructure accordingly.
4. Using a single tool to create tests and monitors has obvious advantages in terms of maintenance, learning, and cost.

Tip 2: Create Tests That Mimic Your Use Cases

If you primarily integrate with third-party APIs (such as Twitter or Google Maps), you must ensure that you are aware of any errors before your users become aware. It’s critical that the monitors you construct reflect how you use the API.

For example, if you’re using the Flickr API to retrieve the most recent photographs for a certain Flickr group, make sure your API monitor does the same thing, rather than returning a list of popular cameras (or anything else that is easier to set up). Also, make sure you’re tracking the complete cycle of your use cases; don’t just track the initial API request; track them all, in order, just like your app does. When it comes to monitoring 3rd party APIs, this is a hard one. Frequently, your monitor may want to validate some form of output based on your input. Another example you might want to validate the coordinates or route plan you get back from one of the Google Maps APIs to ensure that you always get the desired results. Unfortunately, Google routinely updates coordinates on the fourth decimal, so if your monitor doesn’t account for this “volatility,” it may fail unnecessarily. The same is true for route planning; if a traffic jam is causing Google to provide an “unexpected” result for a limited time – something for which you should be prepared.

Tip 3: Use A Dedicated Account

Many (most) APIs need you to include credentials or an access key in your requests; ensure you’re using a dedicated account(s) for both your own and third-party API monitoring. This is due to a number of factors, including- It allows you to run your monitors with the same access privileges as your users for your own APIs, so you can notice problems that might not affect “super-user” accounts. It also allows you to manage billing and bandwidth usage separately from your “production” API usage for 3rd party APIs.

Monitor APIs with NetVision Synthetic monitoring

NVSM or NetVision Synthetic Monitoring is an active monitoring approach through the simulation of typical user navigation paths using scripts. It monitors availability and various metrics of performance for critical web pages. It is based on multiple locations and supports script recording via multiple channels, such as desktop, mobile, etc.