redirect_to doesn't work well for RESTful apps?

Question

As a long-time Ruby and Rails user, it never struck me until today to really think about the get-and-redirect pattern in Rails. The typical example of this would be calling a create() action, and then redirecting the user to a show() action to display the newly-created item:

class JournalEntries

  def index
    @entries = JournalEntry.all
  end

  def create
    @entry = JournalEntry.new( :name => "to-do list" )
    @entry.save
    redirect_to :action => "index"
  end
end

However, this has the inherent disadvantage that you are doubling your network traffic. This both slows down your users' site experience, as well as increasing your bandwidth charges.

So why not just do this instead:

  def create
    @entry = JournalEntry.new( :name => "to-do list" )
    @entry.save
    index

Same output, and no extra overhead required. But in addition to this, there is an even more substantial problem: redirect_to can only redirect using GET. This causes major problems for RESTful apps that use four different HTTP methods.

In my case, I wanted a user to be able to call /journals/8 and retrieve the Journal with that ID. If it wasn't found, I wanted to create a new, empty Journal object. In either case, the Journal object would then be sent to the caller.

Note that the create() method in RESTful Rails is routed from "POST /players". But since redirect_to (and the underlying HTTP redirect) can only send GET requests, it actually redirects to "GET /players", which is the index() method. This behavior is clearly wrong.

The only solution I could think of was to simply call create() instead of redirect_to() as in my example above. It seems to work fine.

Any thoughts on why redirect_to is preferred to calling actions directly?

Answer 1

I'm a Python/Django person, but the reasons for the redirect is language agnostic:

1. If they do a page refresh they don't get that annoying "Resend data?" popup.
2. This gives you a completely clean, RESTful URL for the page they are looking at. If you used POST it might not matter that much, but if GET was used for the update then you definitely want to get rid of any dangling params.

Answer 2

If they do a page refresh they don't get that annoying "Resend data?" popup

It's not just that the popup is annoying (and makes no sense to most users) -- if the user clicks "yes, re-do the POST", he'll end up creating another Journal Entry (or whatever).

Also, it's annoying for the URL to read /posts/create instead of /posts since the user cannot copy / re-use it.

Answer 3

The reason for it is as you point out. You redirect to a GET request, which is correct when it comes to REST (only do updates with POST/PUT, only get data with GET).

A redirect surely gives a little overhead with the redirect, but since no data is actually being sent between the browser and the server except for the POST data and the redirect (which is only sending the new url to the browser) I don't think that the issue of bandwith is of concern.

But on another point, you should not redirect to /journals (by calling redirect_to :index), you should redirect it to the newly created journal entry (by calling redirect_to @entry) which will work if you set up the routes correctly by, for instance map.resources :journals

Update:

I think, for creating the Journal when one doesn't exist, you should ask the user for more input. What is the reason for you to create the entry? The entry should have some text or some other input from the user, so I think from a REST (and rails) perspective you should actually redirect it to the new() method (with a GET request) where the user can input the additional information, that one will then POST the input and create the entry and after redirect to the newly created entry.

If you don't have any extra information that needs to put in, I'm not sure how to do it in a RESTful way, but I would probably have done it by putting the creation logic in a separate method that I would call from the create() and the show() method and then just continue with the show(), not redirecting at all, but also not calling the resource method.