URL redirects can often give developers fits of rage. They often crop up unexpectedly (like when you inadvertently request http://yourapihere.com instead of https://yourapihere.com) and every client handles following them differently. When testing your APIs, sometimes you want to follow a redirect and other times you need to validate that you were returned a valid status code (201, 301, 302, etc.) with the Location header set.
Below I'll cover the two most common scenarios for dealing with redirects in your Runscope Radar tests.
Runscope Radar does not follow any redirects unless you instruct it to. This is to allow you validate redirect responses (see below) and make it so you can be certain any request in a test will only have one request and one response.
Quite frequently you'll want to follow the redirect returned in a response and make an immediate subsequent request. For instance, when creating a new item, the response may return a 201 Created with the Location header set to the URL for the newly-created item. You can then request that URL to retrieve the item.
To accomplish this in Runscope Radar we're going to use Variables. Variables are a way to extract data from one response and use it in a later request.
Using Variables to Extract and Follow Redirects
In the request that returns the redirect information, click Edit Assertions & Variables and then Add Variable. For the source, select Response Headers and for the property, enter Location which is the name of the header. Give the variable a name like redirect_url.
In the next request in the test, edit the URL to contain the variable:
Now, when you run your test, the URL value from the first response will be used to execute the second request. In the test run detail, we can see the URL was set properly:
Validating Responses that Contain Redirects
If you have an endpoint that returns a redirect and you'd like to write a test to confirm that it properly responds, you can do so with a pair of Assertions. Here's an example set I'm using with our sample API endpoint that checks for the correct status code along with a properly set Location header: