In previous posts we covered why it’s important to monitor APIs and how to monitor and validate data from APIs. In this post we’ll focus on a simple but key feature that helps Splunk Synthetic Monitoring users create robust checks for availability, response time, and multi-step processes: Request Headers
What is a Request Header?
When we talk about Request Headers, we’re referring to fields passed along in the header sections of HTTP requests. Request Headers can include rules and settings to define how an HTTP transaction should operate.
There is a standard set of supported Request Header types that have specific names and purposes. Some common examples of Request Headers would be:
- Authorization: Send credentials for basic HTTP authentication to give permission for access
- Cache-Control: Tell the browser how long a resource is eligible to be cached and re-used
- Content-Type: Tell a server the MIME type of the body of a request so that the server knows how to parse the data
- Cookie: Set a cookie to be stored in the browser so we can track state or sessions
Some developers may also implement Custom Request Headers with custom names. It’s common to see Custom Request Headers with a pre-fix of “X,” for example: X-Http-Method-Override could override the request method from something like POST to another method like PUT or DELETE.
Depending on how a site or application works, Request Headers may be a critical part of requirements for an active monitoring test’s configuration in order to effectively simulate a transaction. For example, if we need to actively test the way that a checkout process works when a visitor is cookied, then we’ll need some way to set that cookie with a Request Header when we build an active test on that transaction.
How can we use Request Headers in API Checks?
Splunk Synthetic Monitoring’s API Check helps us monitor the availability, response time, and data quality for transactions with APIs. With an API Check, we can set request headers with each Request as part of a transaction.
Consider a scenario where we need to POST username and password credentials to access some information. Then once we’re logged in at that endpoint we need to store and set a session ID in order to pre-populate other components specific to our session.
When building the steps for an API Check, we can click + Add a Request Header to supply one or more headers at each request step.
In the example above, we’re using Splunk Synthetic Monitoring’s API Check to:
- Make a request to POST a username and password to an endpoint to log in
- Extract a session ID from the response body using JSON path and save that ID as a variable that can be re-used in future steps
- Make a request to POST to a different endpoint with the Session-id in the Request Headers
We could continue to add more functional steps to this transaction or add an Assert step to confirm that the session ID is set as expected.
Why is this valuable?
Request Headers for API Checks seem like a no-brainer today, but our attention to this feature didn’t originate in conversations about requirements for our new API Check; user requests for Request Headers helped us discover that the API Check feature might be worth developing.
Splunk Synthetic Monitoring users let us know that they needed the ability to add Request Headers to each step in their existing Uptime checks. As we continued to have conversations with people about how they expected Request Headers to work within their Uptime check settings, we learned that many teams needed this functionality so that they could monitor robust functionality of APIs. This sparked more conversations that helped us scope out the requirements for a brand new type of Splunk Synthetic Monitoring check specifically designed with API monitoring in mind.
We’re happy to support the ability to set multiple Request Headers for individual steps in transactions as part of our new API Check feature. We know these super basic components open up endless possibilities for simulating and monitoring API transactions.