HTML->HTTP->Hypermedia

2010-02-02 @ 10:24#

i've been contemplating various flavors and forms of HTTP and REST over the past few weeks; all part of a master plan to wrap my mushy brain around the varying degrees of compliance and complication that come w/ crafting credible web apps (not so easy to say or do).

along the way i've bumped into a valuable scale first outlined by Leonard Richardson (The Maturity Heuristic) and also mentioned by Jim Webber (The Confusing Bit from REST). It's been referred to by different names; the one i use is the Richardson Maturity Model (RMM).

i've sometimes found it useful to express the same prinicples embodied in RMM from a different perspective; in a model i call the HHH Scale. but i'm getting ahead of myself...

RMM

The referenced presentations are well worth a look, but here's RMM in a nutshell:

Level 0
  • Single URI, Single verb
  • SOAP, XML RPC, POX
Level 1
  • Many URIs, Single verb
  • URI Tunnelling (e.g. ASP.NET, JSP, etc.)
Level 2
  • Many URIs, many verbs
  • CRUD services (e.g. Amazon S3)
Level 3
  • Level 2 + Hypermedia
  • RESTful Services

i like this model because it expresses, in just a few statements, relationships between a wide range of application types that all 'work' on the Web today. it also sends the message that items farther along in the model are 'more mature' than earlier ones; a handy value judgement when you're working to make a point [grin].

however, the RMM has a decidedly server-side tinge when describing the maturity of Web applications. the examples and descriptions employed as illustrations typically approach the topic from the POV of those responsible for implementing web services hosted on an HTTP server.

sometimes i am talking with folks that spend most of their time on the client-side of the equation. for them, talk of SOAP, RPC, and the like, are not within their usual vocabulary. consequently, i have come up with a slightly different version of the maturity model; one i call HHH or HTML->HTTP->Hypermedia.

HHH

this expression of Web app maturity highlights common views of the Web held by those who are in charge of creating the heavily scripted, Ajax-ified, DHTML-powered Web 2.0 applications most of us use every day.

the HHH model has three different levels:

HTML
devs at this level view Web applications through the prism of common HTML Web browser limits and the semantics expressed in the HTML Document spec; namely two possible HTTP verbs: GET, POST and a single progammable media-type: text/html.
HTTP
devs at this level see Web applications constrained by a basic understanding of the HTTP Protcol spec; meaning the four most often-used HTTP verbs: GET, PUT, POST, DELETE and simple data-oriented meda-types application/xml and application/json.
Hypermedia
devs at this level consider Web applications to be rooted in the notion of state transfer via hypermedia links; an idea first outlined by Roy Fielding in Chapter 5 of his dissertation. they recognize value in the rich link semantics within the HTML media-type and know there are other media-types (e.g. application/atom+xml) that reflect the same support for state transition links as a way to induce application flow. these devs also understand the importance of the HTTP spec as a starting point for building applications that not only use the full range of HTTP verbs, but also implement a powerful control data model (HTTP Headers) that allows both clients and servers to take advantage of shared caches, conditional requests, extensible authentication, and other services that make up the infrastructure of the World Wide Web.

whether you view this issue from a server-side or a client-side perspective, the farther along you go in the models the more felxible, scalable, and robust your applications become. it is also true that applications reflecting higher maturity levels are more demanding to architect and implement; not always more complicated, but usually more involved. in my experience, well-implemented hypermedia Web applications almost always look deceptively easy; and that's the beauty, the challenge, and the reward of it all.

so: how rewarding, challenging, and beautiful are your Web applications?

code