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

Question

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, ne

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

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 3

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 4

I won't go on to explain more about REST since I think that has been answered 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:

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 Rails' default route and this is something that RESTful routes (with subdomain extensions) or only named routes (map.connect 'foo' ... ) can fix.

Answer 5

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 6

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 described.

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.