What are the benefits of REST in plain English?

[JN_Coward]

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

/Jonas

[JN_Coward]

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.

[Rimantas_Liubertas]

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

Don't forget respond_to: one of the most elegant and RESTy things!
Straight from http://tinyurl.com/3bo9na :

== 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

[Jim_Morris2 (Jim Morris)]

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.

[JN_Coward]

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