Post

Author

Password

URI Delete Entry?

Title

Content

<div>There's no denying that Roy Fielding's 
<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">thesis</a>
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 
<a href="http://www.ics.uci.edu/~rohit/DecentralizingREST.pdf">Decentralizing
REST</a> (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 
<a href="http://www.mnot.net/cache_docs/">Caching Tutorial</a>.
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 
<a href="http://www.oreillynet.com/pub/wlg/7766">Semantic MVC</a>,
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
:
<ul>
 <li>
 Model - URIs, resources as data/document
 entities</li>
 <li>
 View - resource representations, data exposed by
 services, end-user applications like browsers and
 newsreaders</li>
 <li>
 Controller - HTTP methods and controls, business
 logic embedded in applications</li>
</ul>
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 
<code>private</code> 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]
</div>