What are the benefits of REST in plain English?

rubyonrails-talk
1

Webservices are nice and all, but it's not the reason why I use map.resources. In fact most of the time I will not implement webservices at all except for where I need them, since this is additional code that might break and will probably be untested. Besides all those respond_to blocks make controllers a pain to read.

The term REST has in the Rails world become almost synonymous with map.resources, but it's not, really. REST are web services, map.resources is just a different way of organizing your controller, and to me it makes perfect sense, so let me explain:

- you know where everything goes Before REST came I (and pretty much everyone else) never really knew where to put stuff. Say you have a Post model and a Comment model, for comments there will only be add and delete, not the full set of CRUD operations. Now you're unsure, do I create two seperate controllers for this or do I create just one? With map.resources the answer is obvious, two models = two controllers. Without map.resources everyone stuck to their personal preference, which ended up becoming a horrible mess when collaborating with other people. Now this is just one example, there are other such organizational things in controllers that are made way easier by map.resources.

- all that hassle with GET and POST and GWR is finally gone. Always needing to protect your methods from destructive GET requests was a pain, and it was inelegant. Say you would have something like 'verify :method => :post, :redirect => blah' in your controller, now that is just ugly. No such hassle with map.resources.

- No leeky URLs Honestly, having a /person/create URL is stupid, and granted it was possible to have /person/new be both form and post method, but that led to some seriously ugly controller code.

- Prettier URLs oh yes, they are prettier /person/1 tops /person/show/1 by miles imho, and person/jncoward is waaay better than person/show/jncoward, no?

- Ability to selectively 'turn off' controllers. Need to disable a feature for a while? No problem, just comment out the map.resources in your routes file and it's dead and gone.

- Named routes mean none of that stupid curly bracket nonsense Need to set the class for a link? So what looks better?

link_to @user.name, { :controller => 'person', :action => 'show', :id => @user }, { :class => 'delete' }

or

link_to @user.name, user_path(@user), :class => 'delete'

hey or even:

link_to @user.name, @user, :class => 'delete'

There are probably some further reasons, this is what I came up with off the top of my head. So give map.resources a spin, you'll very probably like it :stuck_out_tongue:

/Jonas

2

Hmm just realized that this was probably not so friendly to non- programmers, but I suppose not so many of them will read this.

Also came up with another reason map.resources rocks:

- you don't have to check for the existence of an ID. what happen when someones enters /people/show or /people/edit? Why an error of course! What happens when someone enters /people with map.resources? It shows the index page.

3

There are probably some further reasons, this is what I came up with off the top of my head. So give map.resources a spin, you'll very probably like it :stuck_out_tongue:

Don't forget respond_to: one of the most elegant and RESTy things! Straight from Ruby on Rails — Rails 1.2: REST admiration, HTTP lovefest, and UTF-8 celebrations :

== quote == Formats and respond_to

While respond_to has been with us since Rails 1.1, we've added a small tweak in 1.2 that ends up making a big difference for immediate usefulness of the feature. That is the magic of :format. All new applications will have one additional default route: map.connect ':controller/:action/:id.:format'. With this route installed, imagine the following example:

class WeblogController < ActionController::Base   def index     @posts = Post.find :all     respond_to do |format|       format.html       format.xml { render :xml => @posts.to_xml }       format.rss { render :action => "feed.rxml" }     end   end end GET /weblog # returns HTML from browser Accept header GET /weblog.xml # returns the XML GET /weblog.rss # returns the RSS Using the Accept header to accomplish this is no longer necessary. That makes everything a lot easier. You can explore your API in the browser just by adding .xml to an URL. You don't need a before_filter to look for clues of a newsreader, just use .rss. And all of them automatically works with page and action caching.

Of course, this format-goodness plays extra well together with map.resources, which automatically makes sure everything Just Works. The resource-scaffold generator even includes an example for this using format.xml, so /posts/5.xml is automatically wired up. Very nifty!

== end quote=

Regards, Rimantas

4

I think this bit is wrong...

- all that hassle with GET and POST and GWR is finally gone. Always needing to protect your methods from destructive GET requests was a pain, and it was inelegant. Say you would have something like 'verify :method => :post, :redirect => blah' in your controller, now that is just ugly. No such hassle with map.resources.

even the default routes.rb still has

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

and as long as it does you can access any controller action with a GET, and yes you can then delete something with a GET. So I still have verify :method => :put, or :delete or :post in all my controllers, it is just safer that way.

5

wolfmanjm,

there is nothing stopping you from removing the map.connect statement. In fact, I allways get rid of all the junk in routes.rb. If you do that (and if you're really using REST you should) then no, that bit is not wrong, since map.resources will only expose those actions for PUT, POST and DELETE requests. After all, they have the same URL. In that case the verify statement is not safer at all, it is only redundant.

/Jonas