mca blog

in my continued journey through the 'zen' of HTTP/REST programming, i've hit another 'ah-ah' moment.

It's all about the Representation, stupid!

yep, i get the importance of media-types and the reason that supporting multiple media-types is important. once i was able to add the ability to sniff (and interpret) the Accept header in an HTTP request, i was able to start crafting alternate representations of the same resource. and *that* finally rang the bell in my head that resources are *not* the thing that folks see when they make a request to a web server. they see a -representation- of the resource.

of course, the resource is just a 'version' of the actual item stored on the web server. maybe it's a row of data in a database. maybe it's a file on disk. maybe it's a *part* of a file on disk or a 'view' of serveral rows and tables in the database, etc. that's been understood (by me at least) for quite a while. the resource is just a version of the underlying data.

but now i see that the representation is just one of the possible renderings of that resource. and that supporting multiple representations is a big plus. esp. if you want to support machine-to-machine versions of the resource for programming purposes.

that leaves just some clean-up work around the edges to make sure that it's (relatively) easy to get the proper representation back to the client. for example, in my current model, i set a 'default' media-type and a set of laternate media types. if the server cannot tell which type you prefer (or if you tell the server just "*/*", you'll get the default media type. that makes setting the default to "text/html" kinda nice since you can easily browse the resources with a common web browser.