Skip to main content

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.

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.

Popular posts from this blog

Python script to set genre in iTunes with Last.fm tags

Now that I have started to seriously use iTunes I figured it might be nice to have the genre tag set in a meaningful way. Since I have a reasonably large collection of mp3s doing that manually was out of question - I wrote me a Python script to do that. There seems to be a large demand for such a functionality (at least I found a lot of questions on how to automatically set the genre tag) so maybe someone else finds the script useful. It is pasted below. General Strategy The basic idea is to use Last.fm's tags for genre tagging. In iTunes the genre tag is IMO best used when it only contains one single genre, i.e. something like "Electronica", not something like "Electronica / Dance". On the other hand dropping all but one tag would lose a lot of information, so I decided to use the groupings tag for additional information that is contained in the list of tags that an artist has on Last.fm. In the example above that would be something like "Electronica, Dan

What is Multi-Tenancy? A closer look

Lately, I had a lot of conversations about multi-tenancy (MT). So I finally wrote up my thoughts on that term. In this post I will argue that MT is a value that depends on a continuous variable. Therefore, any statement about a system being “MT” can only be made in the context of the given requirements. It is not a property of the system itself . I will also show that perfect multi-tenancy is indistinguishable from single-tenancy (ST). MT is a value that depends on a continuous variable Imagine a step-function "ST-MT" (values are either 0 or 1) that determines if a given system is MT (1) or ST (0). That function will look like this: ST-MT = function (system, business requirements) Look at  the function’s arguments: the first one is obvious – the result will depend on the system itself. The second one is more interesting: it is the cumulative set of business requirements . Typically, these requirements will include: Resource sharing: systems typically declare