Why You Need to Monitor Your Product’s External and Internal APIs

If your company provides a web service, then maximizing your site’s uptime and providing your customer with the latest information your service provides should be prime objectives. Depending on what’s happening at the exact moment a customer makes a request to your service (clicks a button, enters text, clicks an image, etc.), your software must include logic that produces a valid response to that request (rather than a blank area on the screen).

When your product depends on APIs, you have to address the likelihood that at some points in time one or more of those APIs (external or internal) will become unavailable, return partial results, or exhibit very slow performance. While your product must respond correctly to all the alternatives, you can focus your limited resources on the API outages that most impact the quality of what your customers see.

External APIs provide input data for your product. Outages or slow performance from these APIs result in your product producing incomplete or null results. Your software can post a time-stamped last valid result, or it can post a message indicating that current data is not available. Which of these to do can be a difficult decision. For example, if your application analyzes financial market data, and your financial data source API goes down for hours, do you present your customers with obsolete information from hours ago? Or, do you simply report that no current data is available? Or could you do a combination of both, reporting that no current information is available, while stating “here’s the data from n hours ago”?

You have little control over what’s happening with external APIs other than your software’s response to their outages or slow performance. It’s with your internal APIs that you have the greatest control for addressing outages and slow performance.

There is a relation between API monitoring and the software development practice known as Continuous Integration (CI). In both cases, a system that changes with time is continuously monitored to assess the “health” of the product, and status messages and alerts are sent to the development and/or quality assurance teams to make them aware of new issues. In the case of CI, the software is typically tested and evaluated on a daily basis. This is sufficient when teams are developing unreleased software. But status of an active online product requires monitoring at a much smaller time increment (for example, the API Science platform offers monitoring of APIs and alerts at one second increments).

Monitoring the APIs that are critical for your product, combined with alerting your software development and QA teams immediately when something has gone awry, will enable your team to address problems within your internal APIs and software, and also enable your software team to create appropriate responses to your customers when external APIs fail.

–Kevin Farnham