Redirects in Web Request

1

Hello,

we're encountering the following situation:

  • We are interacting with a custom REST API provided by a low-code platform.
  • One of the endpoints allows for deleting records by calling a DELETE method on an endpoint url structured as https://{base_url_of_our_tenant_on_the_lowcode_platform}/api/object/{id_of_the_record} .
  • After executing the delete, this endpoint redirects to another, final endpoint /api/success which only serves to provide a status header (200 OK) and status message in the body. In the Request Header, a "Referer" key is added with the URL of the original request.

When calling the DELETE endpoint in Postman, provided the id in the URL can be resolved to a given record:

  • using the default Postman settings, the record is deleted and we receive the expected response (200 OK). We see that the DELETE request was followed by a GET request on the final endpoint.
  • when not allowing redirects (see screenshot below), the record is deleted and we receive a 302 Found. The logs only show a DELETE request.
  • when allowing redirects again, but enabling the 'Follow original HTTP Method' option, we receive a 404 Not Found. The original DELETE request if followed by a DELETE request on the final endpoint.

When calling the DELETE from the EasyMorph (iterate) web request action:

  • the record is deleted, but we receive a Status 404 Not Found

That's a long explanation for a set of short questions:

  1. Does the (Iterate) Web Request action allow for redirects?
  2. If so, does is stick to the original HTTP Method when following the redirect (in this case, DELETE) ?
  3. How would you assess the feasibility and value of adding options on the Web Request actions to manage these settings, similar to the Postman options mentioned above?

image
image922×212 19.3 KB

2

Hi

Does the (Iterate) Web Request action allow for redirects?

Sure, the (Iterate) Web Request automatically follows HTTP redirection headers to the new location of the resource.

If so, does is stick to the original HTTP Method when following the redirect (in this case, DELETE) ?

It depends on the HTTP redirect code.

The HyperText Transfer Protocol (HTTP) 302 Found redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. The specification requires the method (and the body) not to be altered when the redirection is performed.
However, for historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request

So, the HTTP 302 Found behavior is equivalent to the case

The original DELETE request is followed by a DELETE request on the final endpoint.

but there is an exception to the rule

The original POST request is followed by a GET request on the final endpoint.

When you want the redirect method to be changed to GET, the API server must return the HTTP 303 See Other instead. The method used to display this redirected page is always GET.

Another HTTP 307 Temporary Redirect redirect status response code indicates that the requested resource has been temporarily moved to the URL given by the location headers. The method and the body of the original request are reused to perform the redirected request.
The only difference between HTTP 307 Temporary Redirect and HTTP 302 Found is that HTTP 307 Temporary Redirect guarantees that the method and the body will not be changed when the redirected request is made. With HTTP 302 Found, some old clients were incorrectly changing the method to GET.

Summary table

Method 301 302 303 307
* * * GET *
POST GET GET GET POST 
301 & 302  - All methods are redirected to the same method but POST. POST is redirected to a GET.
303 - All methods are redirected to GET
307 - All methods are redirected to the same method.

How would you assess the feasibility and value of adding options on the Web Request actions to manage these settings, similar to the Postman options mentioned above?

We'll discuss this internally.

2 Likes
3

Many thanks Constantin for the extensive and clear answer! I learned something :wink: We asked the developer of the low-code platform to use the 303 status code after the initial request, instead of the 302. I'll keep you posted on the success of our data interaction after that change.

4

Thanks.
I've updated the previous post and added a redirect table and clarification.

1 Like
5

Hi.
A short update. We've discussed this internally, and currently, we have no plans to add options to manage the WebRequest redirect behavior.

By the way, the EasyMorph Server has a built-in custom API server. That allows users to bind their EasyMorph project to a custom API endpoint. The server is fast and easy to use. So you could develop a server part and a client part with EasyMorph :grinning:.