Monitoring Your API’s Performance Using the API Science API

If your product depends on your own internal API, or if your primary customers are users who use your API, then you need to know when your API’s performance is experiencing problems. In my last post I described how you can use the API Science Uptime Report to address an unexpected massive outage related to your product.

However, an outage of your product isn’t the only problem your team must address. If your customers expect to receive a result from your API within a number of milliseconds, because their product or your own promises to provide up to date information at that frequency, then those products will appear to be at least partially down if your API suddenly ceases to provide results at the promised frequency .

You have a developer team and a quality assurance team, but they can only address issues based on receiving data they can analyze.

Here is where you can utilize the API Science Performance Reports API. This provides your team with the information they need to analyze sudden changes in your API’s performance, consequently providing your management team with the ability to succinctly inform your user community about what’s happening, why it’s happening, and how you’re working to fix whatever can be fixed near-term. For example, if the problem is the result of a global cyber attack, you could message your customers stating that the global attack is why your product appears mostly down.

Your software can access a report on your API’s performance over the past day using a curl command like this:

curl 'https://api.apiscience.com/v1/monitors/1572xyz/performance.json?
preset=lastDay' -H 'Authorization: Bearer NN_6xbe...'

Here, I’m requesting the performance date for the past 24 hours for my monitor 1572xyz, passing in my authorization code for accessing the API Science API. If my monitor runs once an hour, this request will return a JSON response structured like this:

{
    "meta": {
        "status": "success",
        "numberOfResults": 24,
        "resolution": "hour",
        "startPeriod": "2014-09-01T18:00:00Z",
        "endPeriod": "2014-09-02T19:00:00Z"
    },
    "data": [
        {
            "averageResolve": 2.53,
            "averageConnect": 83.73,
            "averageTransfer": 415.84,
            "averageClosing": 480.71,
            "averageTotal": 982.83,
            "startPeriod": "2014-09-02T18:00:00Z",
            "endPeriod": "2014-09-02T19:00:00Z"
        },
        {
            "averageResolve": 2.46,
            "averageConnect": 85.81,
            "averageTransfer": 399.07,
            "averageClosing": 462.27,
            "averageTotal": 949.62,
            "startPeriod": "2014-09-02T17:00:00Z",
            "endPeriod": "2014-09-02T18:00:00Z"
        },
        ...
    ]
}

The preset tag can also be used to request performance data for the lastWeek.

The example report shows that all 24 API call results were successful. The data section shows the details for the calls during each of the past 24 hours. This particular example illustrates what your platform might consider to be a normative situation: the resolve, connect, transfer, closing, and total times for the API calls were similar.

However, if your software automatically accesses this data on an hourly or more frequent cadence, and it analyzes differences between the reported timings, it will be possible for you to notify your team of potential emerging performance problems that will be affecting your customers, even though your product is not technically down. A much longer than normal delay in the call to a critical API will make your product apper down to some of your customers, due to time-outs along the data chain between that critical API and the screen those customers are accustomed to seeing when they click on your app.

You can use the API Science Performance Report API to integrate monitoring of the APIs that are crucial for your product into your software workflow. When adverse performance changes occur, you’ll want your team to investigate why this is happening, determine if there is a viable solution, or decide that a message should be sent out to customers describing why they might be experiencing temporary performance issues.

–Kevin Farnham

Leave a Reply

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