H3RALD: To REST or not to REST?

To REST or not to REST?

h3rald — Mon, 24 Sep 2007 05:48:00 -0600

Lately I’ve been reading quite a bit about Rails’ REST approach, and to be totally honest I’m not 100% convinced it can always be a good idea. The purpose of this post is to re-evaluate the situation, and ask other people their opinion on the matter.

Let’s see…

Key Benefits

To cut a long story short, from my understanding REST can be a good thing because:

It introduces the powerful concept of “resources”, which is independent from the presentation. This basically means that you can have your “resources” represented in HTML. XML etc. etc. “for free”. If you are making an extensive use of web services, this is truly a bless.
Each CRUD action is carried out using a different HTTP command (get, post, put and delete). At present, because most browsers don’t understand PUT or DELETE requested, this is somehow simulated by Rails.
By thinking and modeling your application in terms of resources, everything should always be “in the right place”.

Downsides?

Let’s now try to summarize what made me think more carefully this approach…

While I really like Rails’ convention over configuration philosophy, this sounds a tiny bit too extreme for me. In the end it could be good, but it requires developers to completely re-think the way they develop their application in order to be 100% RESTful.
URLs aren’t that pretty anymore. While someone suggested a way to improve the way RESTful URLs look, that sounds like extra hassle to me. It’s subjective, I know, but I really don’t like using IDs in the url… I’d rather go for an univocal code any day (check out this site… I don’t even like dates in my blog).
Sometimes, it may take quite a bit to figure out how to model some functionality using resources. While it is straightforward when you want to perform CRUD operations, modeling a search action or authentication may be a bit tricky and may also feel a bit forced. Again, maybe it’s just me.
It may be a bit too early to take full advantage of this approach. PUT and DELETE are simulated, and this doesn’t sound right—agreed, that’s the only way for now, but it still sounds like a forceful workaround. Browsers are not RESTful (yet)!
All resources are virtually accessible by a URL. I’m not a security expert, but this scares me a bit.

Here are some posts which made me think a bit:

Looking for a good argument against REST

RESTful Myths: Unraveling the Confusion

Why Can’t Web Apps Be REST-ful?

The bottom line is: is REST really worth the hassle? Especially for small and simple applications like a blog, is it really worthwhile to coerce myself to adopt a RESTful approach when I could accomplish exactly the same things with much less hassle?

In other words, is REST really the answer to everything or in some cases it is just not necessary?

And also (OK, this may sound harsh and impolite): does it really make sense to push people to adopt a RESTful approach no matter what? Sometimes someone may get the feeling that Rails is all about REST now. Is that true, or is there still room for ~~freedom~~ other views?

Looking forward to hear your comments, but please be nice and civilized!

"To REST or not to REST?" by plop

Wed, 28 Nov 2007 16:00:17 -0700

oooh nasty code display in my previous comment…

that’s better: http://pastie.caboo.se/123207

then write user_path(user) or user_path(user.login)

"To REST or not to REST?" by Plop

Wed, 28 Nov 2007 15:45:45 -0700

Nobody asks you to use integer as id :)

/users/plop

meaning params[:id] == “plop”

class User < AR::Base def self.find(args) if args.first.is_a?(String) and !args.first.numeric? find_by_username(args.shift,args) or raise ActiveRecord::RecordNotFound else super end end end

def to_param
  username
end

"To REST or not to REST?" by Matt Beedle

Tue, 25 Sep 2007 05:00:35 -0600

Hi Fabio,

The home page, contact-us, terms, disclaimer, etc are not RESTful. These are just normal mapped routes as they do not really correspond to a resource. I know it is easy for beginners to get confused when learning REST based design for the first time, I certainly did. One could decide to create a contact_us controller, a terms controller etc, each with just a show action to render the page. Obviously this would be overkill.

A more viable approach could be to create a foo controller with custom routes for each page. However, this is unnecessary.

The point I am trying to make is that REST is not a mutually exclusive design methodology. It works very well for database driven sites, and this is where is should be used. Where it doesn’t fit, don’t use it. A site doesn’t need to be entirely REST based. When you think of it in these terms, the question REST or not to REST does not really fit. Maybe something like “When should I REST” would be more apt.

Apologies for the long rambling post!

"To REST or not to REST?" by Fabio Cevasco

Mon, 24 Sep 2007 23:29:43 -0600

@Matt

Thanks for your comment. I bookmarked your article for later use. May I ask why your site is mostly RESTful? What couldn’t you use REST for? That’s what I keep noticing: people end up doing sites which are not 100% RESTful… why?

"To REST or not to REST?" by browsers

Mon, 24 Sep 2007 12:04:32 -0600

can in fact do different HTTP commands (WebDAV). This is how Outlook Web Access works.

"To REST or not to REST?" by MS

Mon, 24 Sep 2007 12:01:28 -0600

Have you seen how Microsoft is suggesting to encode their nextgen REST SDK? Ugly.

http://astoria.mslivelabs.com/Overview.doc

"To REST or not to REST?" by dates

Mon, 24 Sep 2007 11:57:45 -0600

on blogs are good. When research a topic, sometimes it is the date stamp on a blog that lets me know if the information is too dated to consider or not.

"To REST or not to REST?" by Matt Beedle

Mon, 24 Sep 2007 11:51:48 -0600

Interesting article. Just a couple of points I would like to make.

First of, you mention URLs. It’s very simple to make these look nice, just using to_param, and find_by_foo. I have a phone site which is almost completely RESTful. Here is a once of the longest urls: http://best-mobile-phones.org.uk/manufacturers/LG/phones/KE850-Prada/offers

Secondly, although in a pure RESTful design each controller contains only 7 actions, it is easy to add other custom ones. I have written an article about it before here: http://matt-beedle.com/2007/07/17/custom-rest-routes/

The point of REST is more that it encourages good application design. Thin controllers (containing little logic) and thick models (containing most of the logic).