I am implementing an API, trying to stick to a Restful design. We have a use case to accept a POST request, create a resource and return a URL to the client. The client will want to apply some business logic that determines whether the resource should be retrieved from that URL or not. To me it seems natural that the return code should be 303, as specified by RFC 7231:
A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request
However, a colleague disagrees and proposes a 200 response, as the client should not be required to follow the redirect to get the resource - it is up to them. The RFC states
If a Location header field (Section 7.1.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request
I read this to say that a redirection response leaves the decision about whether to redirect or not up to the client. My colleague argues that since browsers and clients automatically redirect we should not be instructing them to do so. Is this correct?
The normal conventions for REST APIs is not to redirect after a POST, there is no need for the PRG pattern for APIs.
The HTTP status code should reflect what has been done (200,201,202 etc.) instead of a redirect status code, as this is much more friendly to consumers of the API.
Browsers do indeed follow redirects, so by doing a redirect you're making it harder to consume your API from browsers - they can't decide to not follow the re-direct.