Avoid redirection

[edsko]

DELETE, PUT, and (in some cases) POST should not redirect, but rather return a document indicating the location of the new resource, if necessary, or other cues to continue browsing.

[dcoutts]

Hmm? Redirection is fine as far as I know.

[edsko]

@dcoutts

git blame TODO
<...>
3d8dfe07 (Matthew Gruen  2010-08-16 18:06:27 +0000 32)  * DELETE, PUT, and (in some cases) POST should not redirect, but rather return
7641f204 (Matthew Gruen  2010-08-22 00:41:20 +0000 33)      a document indicating the location of the new resource, if necessary, or other
3d8dfe07 (Matthew Gruen  2010-08-16 18:06:27 +0000 34)      cues to continue browsing. 

[dcoutts]

I don't think I agree with him. :-)

[dcoutts]

@gracenotes any comments?

[gracenotes]

I think this was originally intended as a RESTful HTTP purist idea. If you created something, return 201, for instance, or maybe 204 for deletion. One of the pragmatic reasons for violating this is that post/redirect/get helps prevent duplicate form submission in web browsers, and it can make for a not-slick user experience.

[dcoutts]

Ah sorry @gracenotes, I didn't read the full text :-)

Yes, using a normal 201/204 response with a body rather than a redirect is indeed reasonable and RESTful. It's not a bad UI necessarily, since it gives you confirmation that something did happen, and the response can link through to the new resource or whatever.

I was just reading the title "avoid redirection" and assumed that meant in general.

Are there many places where we are using redirection rather than a response body for PUT/DELETE?

[gracenotes]

If there is, I don't really remember. Should make a pass-through. This was listed as a general style TODO, and it probably should be in a style guide for writing features.

[gracenotes]

There seems to be some in the PackageCandidates feature (there are FIXMEs there).