Why do I need to work harder to make my Rails application fit into a RESTful architecture?

Question

The Background

I started a Rails project recently and decided to use RESTful controllers. I created controllers for my key entities (such as Country) and added index, new, edit, create, show, update, delete. I added my map.resources :country to my routes file and life was good.

After development progressed a little, I started to encounter problems... I sometimes needed extra actions in my controller. First there was the search action that returned the options for my fancy autocompleting search box. Then came the need to display the countries in two different ways in different places in the application (the data displayed was different too, so it wasn't just two views) - I added the index_full action. Then I wanted to show a country by name in the URL, not by id so I added the show_by_name action.

The Question

What do you do when you need actions beyond the standard index, new, edit, create, show, update, delete in a RESTful controller in Rails? Do I need to add (and maintain) manual routes in the routes.rb file (which is a pain), do they go in a different controller, do I become unRESTful or am I missing something fundamental?

Clarification

I guess I am asking, do I need to work harder and add actions into my routes.rb file for the privilege of being RESTful? If I wasn't using map.resources to add the REST goodies, the standard :controller/:action, :controller/:action/:id routes would handle pretty much everything automatically.

Answer 1

If I go beyond the standard CRUD actions with my models, I normally just add the methods as required. Searching is something I add to many controllers, but not every one, so I add it and maintain the routes normally:

map.resources :events, :collection => { :search => :get }

Moving these actions to an entirely separate controller might keep some of your controllers RESTful, but I find that keeping them in context is far more useful.

Answer 2

REST does not specify that you can't have additional views. No real world application is going to be able use only the supplied actions; this is why you can add your own actions.

REST is about being able to make stateless calls to the server. Your search action is stateless each time as the data so far is supplied back, correct? Your alternate display action is also stateless, just a different view.

As to if they should be manual routes or a new controller, that depends on how distinct the activity is. Your alternate view, if it provides a full set of CRUD (create, read, update, delete) operations would do well to be in a new controller. If you only have an alternate view to the data, I would just add an alternate view action.

In other words, it doesn't sound like your application is failing to be RESTful, it is more an issue of realizing that the automatically generated feature set is a starting point, not a conclusion.

Answer 3

I would treat search as a special case of index. Both actions return a collection of resources. The request parameters should specify things like page, limit, sort order, and search query.

For example:

/resources/index # normal index
/resources/index?query=foo # search for 'foo'

And in resources_controller:

before_filter :do_some_preprocessing_on_parameters

def index
  @resources = Resource.find_by_param(@preprocessed_params)
end

As for index_full and search_by_name, you might look at splitting your current controller into two. There's a smell about what you've descibed...

Having said that, you're absolutely right that there's no point in forcing your app to user restful routes when it doesn't deliver anything over /:controller/:action/:id. To make the decision, look how frequently you're using the restful resource route helpers in forms and links. If you're not using them, I wouldn't bother with it.

Answer 4

To remain RESTful in your design, you need to rethink what you call a resource.

In your example a show action for a search controller, (search resource) is the direction to remain restful.

In mine, I have a dashboard controller (show) and controllers for single fields of in-place ecditors (show and update)

Answer 5

A slightly creative solution gives you the best of both worlds:

Add a new map.connect in your routes.rb and put it above the standard ones. For instance, you can use

 map.connect ':controller//:action/:id'

Now when you use a non-named route like

link_to 'Login', :controller => "users", :action => "login"

the path will be rendered with the double slash like /users//login. This way it will not get processed by show.

For the REST paths, Rails will use the automatic routes provided by map.resources like /users/32569.

Edit: You are not limited to using the double slash (which is a bit weird). You can use anything. For instance, if you use

 map.connect ':controller/a/:action/:id'

then the path

link_to 'Downgrade', :controller => "users", :action => "downgrade", :id => @id

will be rendered with /users/a/downgrade/35, which will of course be serviced by the action downgrade on the users controller (just like we wanted in the first place), and the REST routes are left intact (e.g., users/35 and users/edit/35).

Answer 6

In my opinion they may have gone a bit off the rails here. What happened to DRY?

I'm just getting back into Rails not having done much development with it since beta and I'm still waiting for the light-bulb to come on here. I'm still giving it a chance but if it hasn't happened for me by the end of my current project I'll probably just drop-back to the old standard routes and define the methods as I actually need them for the next one.

Answer 7

Wont go on to explain more about REST since I think that has been answered to death in this question, however I will talk a little bit about the default route.

My main problem with the default route is that if you have multiple sites using the same rails app it can look horrible.

For example there may be controllers that you don't want people to be able to see on one app:

e.g.

http://example1.somesite.com/example_2/foo/bar/1

compare this to

/:controller/:action/:id

This would go to the controller example_2/foo, action bar and id 1

I consider this to be the main flaw of the rails default route and this is something that RESTful routes (with subdomain extensions) or only named routes (map.connect 'foo' ... ) can fix.