Dan Kubb wrote: >>> In fact, if you consider ActiveResource part of Rails, then the >>> lack of >>> treatment for 303 is a bug. Have a look at ActiveResource to see >>> how it >>> reacts to redirect_to following a POST. By that measure, we have an >>> expectation to 303 in the framework. >>> >> I dunno, there's a fine line between 'rest friendly' and 'worrying >> about impractical academic differences'. I'm not necessarily hugely >> opposed to adding a method, but the fact that it's only the two of us >> in this thread seems to say there's not a lot of appetite for this >> stuff. >> >> Anyone else have strong views on the matter? >> > > I'm all for beefing up ActiveResource's handling for each status code, > something is is lacking for all but the most common codes. I also > believe > in using the status code that more closely describes the result to the > user-agent, rather than relying on less specific codes. > > This thread started with an example where Assaf asserted that 303 See > Other > was the most appropriate code to indicate a new resource was > successfully > created as a result of a POST. I don't agree with this. > > The 201 Created HTTP status code's sole purpose is to indicate to the > user agent a new resource was created and where it can be located. > That's what it was designed for. It would be difficult to argue that > *any* 3xx status code is better in *this* particular situation than 201. > > (Please note that I'm speaking about ideal status codes for user-agents > using a REST API. Browsers are a whole other issue, which I'll chime in > on below. I wish that weren't the case, but it is.) > I happen to agree with you. 201 is the more descriptive status code. I went with 303 only because browsers like it, and less specific is also more general purpose (you can use 303 from a PUT). But I am toying with an implementation that uses content-type/method detection, to figure whether it should return 201 or 303.
Assaf > >>> In my opinion that's enough evidence for use to seriously consider >>> how we >>> handle 303 in the framework. >>> >> That's why I applied the patch for :status on redirect_to, I'm not >> denying it deserves thought, just that it doesn't need a method ;) >> > > I agree, for now. However, I do think it would be a useful convention > to use 303 when redirecting a browser after a POST creates a new > resource, > rather than using 302 as most people do. > > While each would result in the same end result with most browser > (a redirection to the Location URL) 303 is a closer match and IMHO > should be preferred when redirecting a browser after a POST request. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
