Using JavaScript to Validate HTTP Headers in API Responses

In my last post, I applied JavaScript to create a timing versus data size validation for my XKCD API monitor:

var timing =;
var size = context.response.meta.downloadSize;

if (timing > 5000) {
        assert(size > 10000, "Download size vs speed issue");

The validation checks how long it took to complete the API check. If the response time was greater than 5 seconds (5000 milliseconds), the size of the API response is examined; if the size is 10,000 bytes or less, an assert is executed, and the validation fails.

This is a simple example. There is much more that can be inspected and validated using API Science’s JavaScript validations capability, and this post sequence will investigate many of the possibilities. In this post, we’ll examine the HTTP Headers that are returned with the XKCD API’s response.

Here are the response headers from a typical call to the API:


You might ask: “Why check the response headers? Isn’t the body all that really matters?” One reason is that, while the body is indeed what matters most in terms of data, the body of an API response can have any structure; whereas HTTP headers are defined by RFCs (Requests for Comments) that are agreed upon by the global World Wide Web community. Currently RFCs 7230 through 7237 define the requirements for HyperText Transfer Protocol (HTTP). Thus, unlike the structure of a response body (which can be entirely freeform), the structure of the HTTP headers segment for every API response is known. This makes analyzing the response headers relatively straightforward, whereas analyzing the response body may require more complex coding.

The HTTP response headers for my monitor’s call to the XKCD API provide numerous opportunities for validating that the latest API check succeeded in the manner your application requires. For example, the “Content-Type” header provides the MIME type with which the response body is formatted (“MIME” is an acronym for “Multi-purpose Internet Mail Extensions”).

The Content-Type header illustrates the value of applying JavaScript to validate headers. If your application expects to receive a JSON (JavaScript Object Notation) response body, then from the point of view of your application, this API is down if the response’s Content-Type header doesn’t include application/json.

You can verify this using an API Science JavaScript validation. Reviewing the XKCD response headers in the example above, we see that, indeed, the Content-Type header includes application/json.

Here’s how we set up a JavaScript monitor validation that will have an API check fail if the Content-Type header doesn’t include this. I edit my XKCD monitor and select “JavaScript” in the Validations pull-down menu:


In the text box, I enter:

var contentType = context.response.headers['Content-Type'];

assert( contentType.indexOf("application/json") >= 0, 
        "Not a JSON response");

The contentType variable retrieves the value that corresponds to the Content-Type entry in the response header. That string is then evaluated using a JavaScript indexOf command. This command identifies the location of the requested string (application/json) within the entire string (contentType). The value 0 means the requested string is at the very beginning of the full string. If the requested string does not exist in the searched string, then a value of -1 is returned.

The assert statement checks if the JavaScript indexOf command returns a value greater than or equal to zero. If the assert fails, a “Not a JSON response” message is issued.

With this validation in place, your team will know if a critical API suddenly ceases to deliver body content in the format your application requires.

–Kevin Farnham