Can anyone explain the benefits of RESTful design so that a
non-programmer will understand? I can’t for the life of me understand
why I would want to go through all the trouble of limiting myself to
seven methods per controller or typing in arcane exceptions if I want to
use an eighth or ninth or tenth. It just seems to make more sense to
keep everything in one simple file.
Sean C. wrote:
Can anyone explain the benefits of RESTful design so that a
non-programmer will understand? I can’t for the life of me understand
why I would want to go through all the trouble of limiting myself to
seven methods per controller or typing in arcane exceptions if I want to
use an eighth or ninth or tenth. It just seems to make more sense to
keep everything in one simple file.
I tried to get an answer to this a while ago. No takers. As near as I
can see, there is only one significant benefit: it makes it super easy
to support a web service. In other words, if you want to give some sort
of access to your data to other websites/developers, then REST makes
that fall-off-a-log easy to do.
Other than that, it seems like it’s just a more convoluted way to do the
same old stuff.
My opinion is that DHH and others find the (somewhat forced) parallels
between the (mostly unused) capabilities of HTTP protocol and CRUD to be
“artistically pleasing”. This has, in my opinion, led them to break
some of the rules found in the 37 signals book regarding feature-itis
and fixing what ain’t broke.
OTOH, DHH and the rest of the Rails Core group were smart enough to
create Rails in the first place and I was not, so I would certainly
welcome some enlightenment on this issue.
cheers,
jp
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
On 27 Juli, 11:49, Jeff P. [email protected]
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 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
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.
Sean,
you’re actually asking 2 questions in one.
The first, what are the benefits of REST (explained in a way non-
programmers can understand).
Take a look at “How I explained REST to my Wife”:
http://tomayko.com/articles/2004/12/12/rest-to-my-wife
The second part of your question is more about “how is splitting
things up better than keeping things in one simple file?”
Unfortunately that’s much more difficult to explain in a way that’s
meaningful to non-programmers. That part of your question is more
about “sound development practices” which can’t be considered ‘rules’
because there’s so many damn exceptions. So when you read this, bear
in mind that there’s a tug-of-war going on between all the objectives
you have. Nothing is absolute.
But basically the issue is “one simple file”.
You could write your rails app as having only one controller. No
views, no helpers, everything done in the controller. Heck you could
even write it as one action in one controller. That’s one file,
but I assure you, it would not be simple.
So you start to break it down into logical chunks. You split things
up according to MVC, asking questions like “does it makes sense for
models to care about http requests?”. All along the way you are
adding files (and classes).
As you do that, it might occur to you that adding classes
(splitting your app into controllers or models or views) has actually
reduced your complexity. Eventually you may come to the conclusion
that a lot of objects which do one thing really well, working
together to complete a task, is a heck of a lot easier to manage
than a few objects which are like swiss army knives.
Which leads us to how Rails does REST by default. By using those 7
controller methods as a threshold, it’s a great reminder to take a
step back and ask: “hmm… am I reasonably separating my concerns by
putting an add_tag action in my articles_controller? How much
simpler would things be if articles_controller didn’t care about tags?”.
You don’t need to subscribe to the whole RESTful or RAILSy way of
doing things. Plenty of great apps don’t.
But my advice to you is, if you don’t know enough to know the
difference, then don’t fight it. It’s encouraging you in the
direction of sound software development practices - pointing out ways
where you might separate concerns in your domain logic.
HTH,
Trevor
Sean C. wrote:
Can anyone explain the benefits of RESTful design so that a
non-programmer will understand? I can’t for the life of me understand
why I would want to go through all the trouble of limiting myself to
seven methods per controller or typing in arcane exceptions if I want to
use an eighth or ninth or tenth. It just seems to make more sense to
keep everything in one simple file.
Actually the 7 methods per controller is a Rails implementation detail.
There’s nothing about REST in general that prescribes this distinction.
Actually there’s nothing about REST that says you even have to use
controllers. What REST does say is that you should model your
application with a couple of things in mind. Off the top of my head I
can think of:
- Everything is a resource, so every URL should point to some “physical”
entity. This means there’s no “action” URL’s like “subscribe” or
“delete”. - The actions are moved to the HTTP methods GET, POST, PUT and DELETE
(there’s a few more, but they’re not interesting in this discussion). So
you’re limited to modelling your application with these actions. - The client should track it’s own state. This means every request to
the server can be handled in total isolation from everything else. - GET requests must never alter the state of the application. No
destructive or constructive GET requests. - GET and PUT are idempotent, doing it once yields the same result as
doing it multiple times.
What this means if that REST prescribes a way of thinking about and
designing web applications. I think I read the expression “A straight
jacket for your mind” somewhere. You may compare it to the opinionated
ways of Rails, where model classes should be in this folder, the
extension of your view file determines which renderer should render it,
database tables must be pluralized, etc. So in the same way as Rails
gives you a set of conventions to abide by in your code, REST gives you
a set of conventions to abide by in the way you design your application
from the users point of view, that is what entry points does the user
have into the application and how is the user supposed to interact with
the application. And this is probably the biggest reason why you would
want to do REST. To have a set of conventions to guide you in your
design, just like Rails guides you in your implementation.
–
Cheers,
- Jacob A.
Jacob A. wrote:
…
What this means if that REST prescribes a way of thinking about and
designing web applications. I think I read the expression “A straight
jacket for your mind” somewhere. >
…
–
Cheers,
- Jacob A.
First, let me admit that while I’ve read the REST stuff a couple of
times and listened to DHH explain it, it has not intrigued me, so I
haven’t tried to use it. From the other responses to the OP’s question,
it seems as if those who have tried it liked it.
Jacob’s reply has me wondering if the “straight jacket” that REST
provides isn’t a matter of choosing whether to write “scaffolding plus
CSS”, or a rich internet app. I very rarely use scaffolding for
anything. I tend to imagine a rich solution to the problem before me
and cook up a solution with lots of ajaxy stuff sliding in and popping
up where needed, etc. I try to make my solution parallel the way a user
would like to view the problem rather than having the organization of
the data define the interface. Jacob’s explanation brings about notions
of a slightly prettied up scaffolding app. A neat and tidy but rather
limited and boring UI that seeks to enforce the organization of the data
on the user rather than working on the data the way a user would want
to.
Again, I speak from my imagination here. I welcome enlightenment from
anyone who has written a “fancy” app using REST techniques.
cheers,
jp
On 27 Jul 2007, at 17:05, Jeff P. wrote:
Again, I speak from my imagination here. I welcome enlightenment from
anyone who has written a “fancy” app using REST techniques.
Would these qualify?
http://demo.placid.be/slideshows/54;manage
http://demo.placid.be/albums/51;manage
http://demo.placid.be/agendas/1;manage
All RESTful routes.
Your argument doesn’t add up for me. I like the way RESTful routes
are defined, the way they behave and how much less code I have to
write and maintain.
Best regards
Peter De Berdt
On 27 Jul 2007, at 17:13, Rimantas L. wrote:
REST has nothing to do with how nice or ugly UI is - it’s all up to
you.
Same goes for data organization - why should user care?
Exactly, UI is view logic, has nothing to do with RESTful routes.
Best regards
Peter De Berdt
<…>
A neat and tidy but rather
limited and boring UI that seeks to enforce the organization of the data
on the user rather than working on the data the way a user would want
to.
<…>
REST has nothing to do with how nice or ugly UI is - it’s all up to you.
Same goes for data organization - why should user care?
Regards,
Rimantas
Peter De Berdt wrote:
On 27 Jul 2007, at 17:13, Rimantas L. wrote:
REST has nothing to do with how nice or ugly UI is - it’s all up to
you.
Same goes for data organization - why should user care?Exactly, UI is view logic, has nothing to do with RESTful routes.
Best regards
Peter De Berdt
Peter, first let me just say that your work is very nice. Also, it may
be that this application might not benefit from anything beyond the CRUD
you’ve provided (a regrettable name that isn’t fitting for your very
nice site) and RESTful routes you’ve used to accomplish it.
As soon as you start using ajax you wind up with lots of additional
controller stuff that doesn’t fit that pattern. In some cases that is
probably worthless fluff. In others it can make a site more useful, and
I try to limit my use of it to those situations.
In defense of my position, I never said “ugly”, I said "scaffolding plus
CSS, which probably should have been CRUD plus CSS. Basic maintenance
of the database (no matter how pretty) works well for some tasks, and
not so well for others. Some apps are more than just a “front end” for
a set of tables in a database. Such apps are not necessarily better,
just different and require a different approach.
BTW, the statement “UI is view logic” seems somewhat oxymoronic to me.
I thought the goal was to limit how much logic one puts in the views.
For me, that means lots of “additional” stuff winds up in the controller
(and helpers).
I agree that a very CRUD centric RESTful app is probably much easier to
write. I plan force myself to find an appropriate part of an app to use
this in so that I can learn more about RESTful routes. Thanks for
helping me learn more about REST. I do believe it has it’s place now; a
shift from my previous opinion.
cheers,
jp
It’s all about design of your domain. Watch this
You won’t regret it.
–
MK
Jeff P. wrote:
just different and require a different approach.
shift from my previous opinion.
You might find Dave T.’ article on the RADAR architecture inspiring.
He raises some of the same issues as you and provides a good description
of the motivation for REST:
http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html
–
Cheers,
- Jacob A.
Jacob A. wrote:
Jeff P. wrote:
just different and require a different approach.
shift from my previous opinion.
You might find Dave T.’ article on the RADAR architecture inspiring.
He raises some of the same issues as you and provides a good description
of the motivation for REST:http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html
–
Cheers,
- Jacob A.
Thanks Jacob, this was brilliant! I think I’m going to build my next
Rails app that way. Best of both worlds, worst of neither. Thanks very
much for pointing me to this excellent article.
jp
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
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.