Is there a way to redirect through a 201 answer?
The RFC specifies that the newly created resource must be specified in the Location
header, and I do specify it. I assumed that the browser would redirect but it doesn't, even if the page has no content.
I want the user, after the POST action, to get redirected to the new resource. I'm therefore tempted to use 303 See Other
but a 201 seems more appropriate.
So, is there any way to automatically redirect popular browsers without user intervention and without relying on Javascript?
I think you're confusing two different semantic responses - one is telling the client that you successfully created a resource, and where it is. Whether the client goes to fetch it or not is a different story.
The second is telling the client that it has sent the wrong location URI for a resource it's requesting - and that it should try again, but with a different URI.
A 303 is appropriate in this case - in fact, it's explicitly recommended for this:
(from rfc)
It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.
The browser will enact a redirect action through one of the 3xx status codes, the specification doesn't define that a user agent must redirect with a 201. You could try sending a refresh header to see if it forces a redirect to the Location
header, but I wouldn't count on it. Why not stick with a 3xx response?
You could send a Refresh
header.
I am dealing with this for the first time, and this is what I have decided to do:
GET /user/new
-> 200 Ok
with user registration form.
POST /user
-> 201 Created
a new user, respond with the same content as the GET /user
route.
GET /user
-> 200 Ok
with the user profile page for the authenticated user, or, for anonymous visitors, 307 Temporary Redirect
to /login
, which links to /user/new
.
update
I have found out that this is a bad idea, because if the user refreshes the page that was rendered as a response for POST /user
, they resend the post data. I will leave the answer here in case anyone else has the same brilliant idea.