Recent posts have talked about the capability the API Science API monitoring platform provides for creating and working with global variables that are maintained across multiple monitors. In this post, we’ll look into the platform’s capability for creating local variables that are specific to an individual API monitor.
The fact is, APIs change over time. Also, your company’s own specific usage of a particular external API may change. And certainly your company’s need to monitor the performance of your own evolving internal APIs will change over time.
Employing API Science’s monitor local variables can make this necessary evolution easier to manage. Instead of creating a new API monitor every time something changes, if you configure your monitor using variables, you can simply change the variable, and your monitor is instantly reconfigured to analyze the performance of your new product.
For example, let’s say we want to create a monitor that sends an HTTP GET request to some
*.com domain, while also sending it a GET query parameter, and a specific HTTP header. To initiate this, from our API Science Dashboard, we can click the “Add Monitor” button. Clicking the “Show Settings” link brings up a page that includes a “Pre-Process Script” field like this:
Here, I’ve set variables that are local to my new monitor to define a:
- testdomain: a portion of the URL this monitor will call;
- queryparam: the value for a parameter this API is configured to receive as part of the GET query URL;
- otherparam: another value the API is configured to receive and process;
- otherheader: the value of an HTTP header this API knows how to receive and process.
So, here, we have configured an easily editable set of variables which can be utilized to create a flexible API monitor that is readily adaptable as the evolution of the external and internal APIs upon which our product depends proceeds.
Implementing Monitor Variables in Your Monitor
To implement these specified variables, we can edit the monitor settings like so:
Here I’m designating that the API I’m calling is
http://, concatenated with the value of my
context.testdomain variable, concatenated with
.com/echo?foo=, concatenated with the value of my
context.queryparam variable. In addition, I’m designating that I’m sending a
myotherparam value of my
context.otherparam variable, and the
X-TestHeader value that’s represented by my designated
Testing the monitor
So, why not test this new monitor? Clicking the “Test Now” button yields this request result:
The variables resulted in this GET request:
This request was sent with an added
X-TestHeader HTTP header with a value of
myheader, and an extra parameter named
myotherparam with a value of
Here’s the response:
The point of Scooterlabs.com is to provide an API endpoint that receives API requests, including variables and headers, and returns information on what was received and how it was processed–basically, the received information was read, turned into a response, and statistics about the transaction are also returned. So, here we see that the designated variables were received and processed into the response message.
This example illustrates how, as you monitor the critical external and internal APIs your product depends on, you can utilize monitor variables to add flexibility to your API Science monitors, in order to address the inevitable evolution those critical APIs will see.