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.


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?

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

NoSQL talk at Developer Summit

Three days ago I had to chance to talk about NoSQL at the Internet Briefing's Developer Summit. On top of general ideas and concepts like the CAP theorem I chose to talk about Apache Jackrabbit, CouchDB and Cassandra. My slides are embedded below.
It was a really good event with interesting speakers and a knowledgeable audience. I was especially pleased that when I talked about CouchDB's HTTP API someone from the audience mentioned that Apache Sling does something very similar for Jackrabbit.
Special kudos to Christian Stocker of Liip for daring to do a live demo of the "real-time web" - he took a picture from his phone and had it pop up on Jabber and Twitter in about 5 secs.
Vlad Trifa has posted a good summary of the whole event (part 1, part 2) - he also gave a great presentation about the application of the REST architectural style to the "Web of Things".

No SqlView more presentations from mmarth.

NoSQL: A long-time relation(ship) comes to an end

(cross-posting from here)

OK, I admit it, declaring that "the RDBMS is dead" is a meme that has been going around the software industry for a while. Remember object-oriented data bases that were supposed to replace the relational ones? Well, guess who is still here. However, despite the RDBMS's amazing survival skills I would like to propose a related prediction:

I believe that the year 2009 will go down in history as the year when the "relational model default" ended. The term "relational model default" was coined by me to describe a peculiar thing that goes on in application development: start talking to your average application developer about some arbitrary business requirement and chances are that simultaneously he mentally constructs a relational model to fit those requirements.
That relational approach to modeling your problem may or may not be suitable. The real problem is that all too often this default does not get challenged. As a consequence,…