What are the benefits of REST in plain English?

Sean Colquhoun 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.

<...>

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

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

Exactly, UI is view logic, has nothing to do with RESTful routes.

Best regards

Peter De Berdt

Jeff Pritchard wrote:

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.

You might find Dave Thomas' 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

It's all about design of your domain. Watch this

You won't regret it.