« The play's the thing | Main | links for 2007-03-14 »

Resource and Representation

written in 2003

Resources

We'll need a basic grasp of a Resource.

In HTTP parlance (or REST, the mandated architecture of the Web), resources are things that are denoted by URIs. Each URI implies a resource. In a positivistic view of things, this could suggest you are creating resources by creating URIs. In real reality new things are not coming into existence, but in web reality, yes they probably are. This should make you suspicious and uncomfortable, in the same way people are suspicious and uncomfortable about dark matter, superstrings or quantum mechanics. Try to find comfort in realizing it's only a model of the web, and only an architectural model at that; one that happens to require the presence of Resources in the same way Plato's cave required things outside the cave to make shadows in the cave.

It's notable that resources are not on the web - you can't reach them or interact with them directly. It's also notable that many many people have built perfectly good websites without ever hearing of, or running into, a Resource.

For the most part, Resources are different from the things people create and manipulate when getting something done on the web; things like web browsers, web servers, web pages, web applications, web sessions and web controllers. I'm saying this because a lot of people you come across working with HTTP aren't thinking about Resources. They're thinking about things like web browsers, web servers, web pages, web applications, web sessions and web controllers. Of course you could assign all of these things URIs and they would be thusly Resources, and 'on the Web'. Sometimes people do just that; for example to provide a management console to a web server, a firewall, or a running web application.

Representations

A Representation is what is transmitted when you "dereference a Resource using a URI"; you know, clicking on a link. They're real, more or less. You can send them over the network, fill up a hard drive with them or use them to attack people's computers; that sort of thing. The current state of of the Resource is represented by the Representation (these things are well named). REST, mentioned earlier, stands for REpresentional State Transfer.

In this model, state results when the application traverses a succession of URIs embedded in Representations; you know, surfing the web. Somebody once said "hypertext is the engine of application state", which is an opaque way of describing "surfing the web". But it is why some people, myself included, are wound a bit too tight about calling HTTP a transport protocol, which is very common. There's no application state in a transport protocol, there's just data and control.

How it works

Now let's gets to the Web's dirty secret - nobody builds applications according to the designated model.

When I say nobody, I mean nobody statistically - the number of web application developers informed by web architectural theory is tiny, really tiny. It's growing as the theory (REST) gets exposure and becomes popular due to push back against Web Services complexity and the fact that some big websites have admitted they use it. All that progress requires significant evangelism (read: being annoying on mailing lists, standards groups and blogs).

So. We have a constellation of Resources, named with URIs and clients using URIs over HTTP to get Representations which contain further URIs. Ok, enough with the theory - does that work? I think it does, and I think it can work better than idiomatic use of the web, but it's a really different way of doing things. The question is like asking do continuations, or events, or futures, or functional programming or capability based security work. Yes they do, but there are vast amounts of knowledge and infrastructure vested in the idiomatic alternatives. You'll be starting from scratch and doing a lot of unlearning. except for the ones you build yourself, the tools will not save you - they're dealing with technical idiom, not technical excellence.


March 14, 2007 12:28 AM

Comments

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1410