09 March 2009

Concepts and a RESTful Web

I just finished reading Ryan Tomayko's really enjoyable blog post "How I Explained REST to my Wife." I also read most of the miles of comments which have built up around this now famous blog post over the past two months. The comments are really very interesting, not so much for what they say, as most are really rather banal, but for what they tell us about Ryan's main point in his description of REST. The comments split pretty much into two topics, leaving out all the "Well done!" and "This is rubbish!" comments. Basically the comments talk of Sexism and What Really is REST?

What interested me about these comments was the hugely diverse readings of Ryan's post. Many focused on how Ryan referred to his wife as "Wife", also arguing that he had implied that his "Wife" was predisposed to be technically incompetent simply by having to explain what are a set of web design principles, and some technical specifications, to his partner. In fact, I do not see that the sexist argument applies at all here. There is no sense that Ryan assumed that his wife was predisposed to technical incompetence, quite the opposite. Though, by Mrs. Tomayko's own assertion, it did make her sound a bit thick. By far the most sexist, and even offensive, statements are to be found in the comments.

What I think is really interesting about the comments, with appologies to the Tomaykos for what they have had to endure, is that these comments counter what seems to be Ryan's main point: that what is really holding back the development of a RESTful Web is the absense of standards. Ryan makes a clear association between the advance of database services on the Web with the acceptance of SQL as a standards query language. He goes on to assert that such a universal standard for REST resources, the nouns in his explanation to his wife, would have an equal or greater benefit.

The comments to Ryan's post counter this arguement by their very diversity. One of Ryan's assertions is that REST resources are "representations" and, hence, correspond to a "concept". After his wife makes clear taht she is not really sure what a URL does, Ryan explains to his wife:

Ryan: Oh, right. Those tell the browser that there’s a concept somewhere. A browser can then go ask for a specific representation of the concept. Specifically, the browser asks for the web page representation of the concept.

The wife has already unquestioningly accepted this association of a representation with a concept, and the two, unproblematically, with a web page when the conversation contiues:

Wife: What other kinds of representations are there?

Ryan: Actually, representations is one of these things that doesn’t get used a lot. In most cases, a resource has only a single representation. But we’re hoping that representations will be used more in the future because there’s a bunch of new formats popping up all over the place.

Wife: Like what?

Ryan: Hmm. Well, there’s this concept that people are calling Web Services. It means a lot of different things to a lot of different people but the basic concept is that machines could use the web just like people do.

Wife: Is this another robot thing?

Ryan: No, not really. I don’t mean that machines will be sitting down at the desk and browsing the web. But computers can use those same protocols to send messages back and forth to each other. We've been doing that for a long time but none of the techniques we use today work well when you need to be able to talk to all of the machines in the entire world.

But what does Ryan mean by "computers can use those same protocols to send messages back and forth to each other"? What messages, saying what, doing what, specifying what, and to what ends? I think this is where Ryan's post deviates from what REST is, to what the Web is, and I disagree with him on what the Web is or should be.

The problem is that Ryan makes a common mistake. He takes the trivial things and makes them seem to be the problem, and, hence, transforms the really complex problems into trival issues (a traditional error that Clay Shirky identified in the Semantic Web arguement back in 2003) . The problem in the above discussion between Mr. and Mrs. Tomayko is not "How do you get machines to pass information back and forth using REST principles?", but "How do people find, understand and use a web page?"

Web pages are not representations of concepts, they are complex performances, accounts. They are purposfully designed and constructed accounts of something. The complexity is extended as a web page, or web resource, does nothing until it is accessed, used and/or read. The really difficult problem in all of this is getting from the web page to a concept period. On top of this, as the long list of comments to Ryan's post demonstrate, a web page does not represent just one concept, but potentially an infinite set of concepts. What is one person's representation of REST, is another person's exemplar of sexism, and another person's evidence of complete missunderstanding. The concept is not in the web page, but in its use. And its use is as diverse as its users.

This is the real rub, whether the web is a RESTful place or a SOAPy place. In fact, I lean very strongly, if not completely, to the RESTful side, but this is not the point here. Whether to REST or not to REST is an important issue, but one, with others such as the Semantic Web, that will continue to get diverted down blind alleys as long as we think that concepts are simple, stable and representational.

No comments:

Post a Comment