Wednesday, March 04, 2009

The misuse of the term "RESTful" in the Rails community

Today I went to a talk at the local Ruby on Rails group. The speaker was quite clueful. He had even implemented his own DSL to describe his business problem. Obviously, the guy was not a noobie in Ruby.

However, what really turned me off was his usage of the word "RESTful". For him, it seemed to be a way to describe the inner workings of his application, like, say, "separation of concerns". RoR guys are generally not the most clueless people, but nobody in the audience challenged him about this. It seemed to be the generally accepted usage of the term in the Rails community.

This made me think that DHH and Rails have done two things to REST:
  • First, they greatly help to evangelize the term "RESTful"
  • Second, they hijacked the meaning of the term and changed it from "architectural style" to "application architecture"
As it happens I listened to a podcast from the Pragmatic Programmers on my way home. It was about the .Net Ruby implementation and, of course, Rails and consequently REST were brought up. One of the speakers said that he was only introduced to REST through Rails. He went on to explain REST in way that confused the hell out of me, but the essence was along the lines of "http is good". If the Rails community is fuzzy about what REST is, people who get it second hand from them are as well.

I believe that a part of the misunderstanding is that the term "architectural style" (as opposed to "architecture") is not understood well enough in the development community. However, Roy Fielding has written a brilliant post about that difference between an architectural style and an architecture: "On Software Architecture".
Web implementations are not equivalent to Web architecture and Web architecture is not equivalent to the REST style.
RESTful-Rails-people please have a look at that post.

PS: Ted Neward had some predictions for 2009 (as I silently predicted, nobody cared that I did not make any predictions for 2009), one of them just came to my mind (emphasis mine):
Roy Fielding will officially disown most of the "REST"ful authors and software packages available. Nobody will care--or worse, somebody looking to make a name for themselves will proclaim that Roy "doesn't really understand REST". And they'll be right--Roy doesn't understand what they consider to be REST, and the fact that he created the term will be of no importance anymore. Being "REST"ful will equate to "I did it myself!", complete with expectations of a gold star and a lollipop.

2 comments:

godot said...

Why didn't you challenge him then? :-)

I see your critisism, maybe we should talk more about what REST is in everyday app design.

The talk was about spidering for data, extracting the data points out of ugly HTML, XLS and others. Restful wasn't there much, but the 'REpresentation' of a state of resources was what it boiled down to. The part visible to users of his app would expose the data via a standard Rails app, which he didn't focus on. But that part would (if done right) be a RESTful representation of the data. So it's not all wrong, is it?

Lukas

Michael Marth said...

> Why didn't you challenge him then?

I should have, of course.

> The talk was about spidering for
> data, extracting the data points
> out of ugly HTML, XLS and others.
> Restful wasn't there much, but the
> 'REpresentation' of a state of
> resources was what it boiled down to.

I did not go into this in my post, but now that you bring it up: the talk was titled Restful Spidering... However, the spidering techniques that were presented were not Restful at all, because they violated the HATEOAS constraint quite severely (URLs were hardcoded, etc). They might be the right thing to do in that scenario, but the Restful label is wrong.

But that is not the purpose of my post, because this argument applies to this one application only.

> The part visible to users of his
> app would expose the data via a
> standard Rails app, which he
> didn't focus on.

When the speaker spoke about REST he talked about the way his app is coded (mentioning controller and method names), not about the external representation of his data. The purpose of my post is to point out this difference. I believe that these two aspects get mixed up in the context of Rails.