HTTP Redirect Calls
Last updated
Last updated
HTTP redirection, also known as URL forwarding, allows an API to provide more than one URL location to the resource in the response. HTTP redirects usually happen due to temporal or permanent unavailability of the application, website, or pages. For example, unavailability due to server maintenance or re-organization of the URL links.
Redirect responses from the server have a 3xx series HTTP status code along with a Location header parameter that provides the URL to the resource’s new address.
In this use case, we have a GET API resource account that returns account details based on the provided ID Query parameter.
Upon previewing the API Client, a request is sent to fetch the account for the given Id. In the response returned the API request is redirected returning a 302 Found status code response indicating that the resource is temporarily unavailable.
It may be due to server maintenance or any other unforeseeable reason. We can see that the Location header parameter is received with the response too. The Value of this header is the address to the alternative resource that must be accessed to retrieve the required account details.
Let’s see how we can configure the API client properties to automatically follow any redirect responses to the new URL Location.
Right-click on the API Client and select properties. Next, navigate to the Service Options window. Here, there are multiple options available to configure the redirect call(s).
Follow Redirect Calls From 3xx Code Responses – This option allows auto-redirecting a 3xx HTTP response to the redirected location URL.
Redirect Authentication Information – This option allows forwarding all the authentication details along with the redirected call.
Redirect Limit – This option allows us to specify a limit to the number of redirected calls followed.
Let’s enable the redirect and authentication options while keeping the redirect limit as 1.
Note: By default, the Redirect Authentication Information and Redirect Limit options are disabled. Only on checking the Follow Redirect Calls From 3xx Code Responses option are they enabled for configuration.
Now, upon previewing the output we can see that a 200 OK status response is received instead of a 302 Found. The request URL field shows that the request was successfully auto-redirected to the redirecting URL.
Now, let’s execute the Dataflow.
Here, we can see the job traces show all steps of the redirected calls including how the authentication information was forwarded along with the request, what was the redirect limit, where the request was redirected to, and if the job executed successfully.
Let’s consider a scenario where the redirected API requires authentication, and we don’t send the authentication information along with the redirect call by unchecking the Redirect Authentication Information option from the Service Options window.
Upon executing the job, we can see that the request is redirected without the authentication information, and as a result, the server sends back a 401 Unauthorized error response.
Now, let’s consider a scenario where an API request hops through more than one redirected call.
The first redirect request returns a 3xx series response. We can see in the Job Trace that on redirecting the request we received a 307-status response indicating that the service is temporarily unavailable. As the redirect count was set to 1 so, only one redirect call was sent by the API Client.
In such a situation, we need to follow all the redirect requests until a 200 OK response is received. For that, we can increase the Redirect Limit count.
For example, we will set the limit to 2 and send the request.
In the Job Progress window, we can see that two redirect calls have been exhausted, but we still received a 307-status response.
Let’s increase the limit to 3 and send the request.
Finally, a 200 OK response is received on the third redirect call.
This concludes how HTTP redirect calls are automated by the API Client in Astera.
