Detecting Failed API Monitor Checks Using the API Science API

In my last post, I illustrated how we can use the API Science Checks API endpoint to gather the results of recent checks for an API monitor. In that post, the example check was a successful call for my “br Ireland” monitor, which queries the World Bank Countries API for information about Brazil from a server located in Ireland.

My “br_Ireland” monitor has a validation setting that requires an HTTP Response code of “200” in order for the API check to be considered successful:

Thus, if a monitor check does not return an HTTP response code of 200, the check is considered to have failed, and the API is considered down with respect to its utility for our product. If this is a critical API for our product, then our own product will appear down to our customers.

Here is an example JSON response for a call to the Checks API for a failed “br Ireland” check (the “body” section is truncated to improve readability):

{
  "meta": {
    "status": "success",
    "numberOfResults": 1
  },
  "data": [
    {
      "id": 121102116,
      "href": "https://api.apiscience.com/v1/checks/121102116.json",
      "status": "failure",
      "statistics": {
        "resolve": 50.06,
        "connect": 0.96,
        "processing": 27.14,
        "transfer": 0.95,
        "total": 79.11,
        "downloadSize": 1565
      },
      "monitor": {
        "href": "https://api.apiscience.com/v1/monitors/1572022.json",
        "name": "br Ireland"
      },
      "calls": [
        {
          "id": 141355405,
          "template": {
            "id": 1324667,
            "href": "https://api.apiscience.com/v1/monitors/1572022/templates/1324667.json",
            "name": null
          },
          "statistics": {
            "resolve": 50.06,
            "connect": 0.96,
            "processing": 27.14,
            "transfer": 0.95,
            "total": 79.11,
            "downloadSize": 1565
          },
          "request": {
            "verb": "GET",
            "url": "http://api.worldbank.org/countries_api/br",
            "headers": [

            ],
            "body": "",
            "params": [

            ]
          },
          "response": {
            "contentType": "text/html; charset=UTF-8",
            "stausCode": 404,
            "headers": [
              {
                "Date": "Tue, 04 Apr 2017 03:57:09 GMT"
              },
              {
                "Content-Type": "text/html; charset=UTF-8"
              },
              {
                "Content-Length": "1565"
              },
              {
                "Connection": "keep-alive"
              },
              {
                "X-Powered-By": "ASP.NET"
              },
              {
                "Set-Cookie": "TS019266c8=017189f947e2cb40b23c9c04eec31cf2f670ff2827dd4f5157e821f795b176569408155f5b; Path=/"
              },
              {
                "Server": "Apigee Router"
              }
            ],
            "body": ... 
"Service ...
Endpoint not found." ...
          },
          "validationFailures": [
            {
              "kind": "Response Code",
              "message": "Response code is not 200"
            }
          ],
          "createdAt": "2017-04-04T03:57:09.000Z",
          "updatedAt": "2017-04-04T03:57:09.000Z"
        }
      ],
      "alerts": [

      ],
      "createdAt": "2017-04-04T03:57:09.000Z",
      "updatedAt": "2017-04-04T03:57:09.000Z"
    }
  ],
  "pagination": {
    "last": "https://api.apiscience.com/v1/monitors/1572022/checks.json?start=121102116&page=179&count=1",
    "next": "https://api.apiscience.com/v1/monitors/1572022/checks.json?start=121102116&page=2&count=1"
  }
}

The response has the same structure as the result I discussed in my last post. The “meta” section shows that the call to the Checks API was successful. The “data” section includes statistics about this particular “br Ireland” check. The “status” in this case was “failure”, whereas the “status” for the result I discussed in my last post was “success”.

This reveals the possibility for your team to develop automated procedures based on the results that calls to the API Science Checks API return. Assume your product depends on the information the World Bank Countries API returns for Brazil. You have an API monitor checking this API at some time cadence (every 15 minutes, for example), and these monitors can send alerts to your team when a critical API goes down. But, using the Checks API response as your input data, you can develop custom software that will automatically react to critical API outages.

For example, you could create an application that parses the Checks API response data to determine the significance of an outage for your product (is the API completely down? is it not returning a complete response? is it stating the information you requested is not currently available?). Or, you could use the response data to assess lags in the response times for important internal or external APIs (if you guarantee your customers a response within 3 seconds, but a critical API has frequently taken 30 seconds to respond over the past few hours, action on your part my be needed: your customers think your app is failing!)…

The API Science Checks API endpoint provides data that enables your team to develop custom software to analyze the performance of critical external or internal APIs that determine how your customers view your product. In my next post, I’ll describe how your team can use this information to automate tuning your API monitors to provide your customers with their best possible user experience.

–Kevin Farnham

Leave a Reply

Your email address will not be published. Required fields are marked *