303 (See Other) is the status code a resource returns to tell the client about the new resource it just created (typically after a POST). 301/302 is the status code some servers return to tell the browser where to go next. It works because browsers ignore the distinction and treat all three status codes the same way, and few people understand the difference. But when developing an application that uses resources (e.g. using ActiveResource), these status codes have distinct meaning. 303 points to the newly created resource, but 301/302 say "this resource moved, please send your POST again to this new location".
In 2.0 we get the convenience of:
def create item = Item.create(params[:item]) redirect_to item, :status=>:see_other end
Regardless, I think there's a strong argument for adding a see_other method. As syntactic sugar, it will help developers who are not quite aware of the difference between 302 and 303.
Another possibility is changing redirect_to, so it defaults to return 303 whenever it responds to a POST. Do the right thing without bothering the developer with the nuances. I'm not sure that would be enough, though.
Let's try a simple scenario. I have a todo list application, the user creates new items using a form, submits the request and gets redirected back to the todo list. Client applications, on the other hand, make POST requests and expect a 303 pointing them to the new resource.
My controller look likes:
def create item = Item.create(params[:item]) respond_to do |format| format.html { redirect_to items_url } format.all { see_other item } end end
The syntactic sugar helps with the distinction, handling both cases, and distinguishing between the browser's 302 and application's 303.
And we can extract this into a further simplification:
def create item = Item.create(params[:item]) see_other item, :html=>items_url end
Comments?
Assaf