Raw

There's no denying that Roy Fielding's thesis is a masterpiece of post hoc system description. The idea of Representational State Transfer has provided a consistent analysis through which the Web can be viewed. But is REST too complicated? That question only makes sense if you add "for what?". The depth of analysis in the paper has certainly been of benefit in the creation of subsequent specifications. In direct practical terms it's informed the design of wiring components, clients, servers, caches etc. It's also lent itself to extension, for example in Rohit Khare's Decentralizing REST (PDF) which can provide a theoretical base for pub/sub on the Web. So I think it's reasonable to say that REST isn't too complicated for these purposes.

But most of the time REST is referred to on the Web these days it isn't with such aims in mind. It's more about shifting data around in a simple-to-implement fashion, one which avoids the brittleness of RPC approaches. Most developers get their basic clients and servers off the shelf, most people use caches (often without realising it), they don't design them. REST in common parlance isn't so much about the architecture, it's about basic practice. It could maybe be summed up as: favour (declarative, XML) documents as payload, use as many of the HTTP methods that you can and use them correctly. Sure, awareness of what's going on at a system level is extremely valuable, but I'd suggest there's probably enough for that contained in the specs (URIs, HTTP etc) and in e.g. Mark Nottingham's Caching Tutorial. While in the process of developing software, all the typical coder (like myself) needs is a reasonably intuitive overview abstraction. Perhaps REST is too complicated for that.

Rather than throw such an assertion out without offering an alternative, here's a thought exercise ( hopefully that phrase will be an adequate flame barrier). Kendall Clark suggested Semantic MVC, using kits like Ruby on Rails with an Semantic Web-oriented datastore. Lot of sense in that. But why not shift a gear to an MVC Web :

• Model - URIs, resources as data/document entities
• View - resource representations, data exposed by services, end-user applications like browsers and newsreaders
• Controller - HTTP methods and controls, business logic embedded in applications

If such a description is to be any use, like its REST big brother it should allow systems to be created based on it and lend itself to extension. Ok, the Ruby on Rails kind of system just about works as a direct overlay. Through a Web lens in that case the data model part is largely hidden (not unlike using private variables in OO code), but the View and Control aren't a bad fit. For extensions, a simple example might be to add XML namespaces to the basic Model. Another possibility might be to shift the business logic from the control and place it in the model in a declarative fashion - that's pretty close to the Semantic Web roadmap.

It's a certainty that other folks have considered this kind of approach, and it might be total straw, but I got to this following a chain of thought that started with microformats (of all things), while just out walking Basildog. Documents versus data, protocols, abstractions, patterns…it surprised me a bit that this led me to wonder about reevaluating REST, so I thought it might be worth writing down.

[Danny]