World Wide Webber


My Books
REST in Practice: Hypermedia and Systems Architecture
Amazon:
US, UK
Developing Enterprise Web Services by Sandeep Chatterjee and Jim Webber
Amazon:
US, UK,
Also available: Korean Edition

My Bookshelf
RESTful Web Services Cookbook by Subbu Allamaraju
Programming Clojure by Stuart Halloway
RESTful Web Services by Leonard Richardson and Sam Ruby
Reflections on QCon REST Track
Posted: 23 November 2008 @ 23:09 UT from San Francisco, USA
Last updated: 23 November 2008 @ 23:10 UT

The QCon REST track, as many of the speaker and attendees have blogged, was simply excellent, not a single dud talk all day.

Having said that, there were three stand-out themes that emerged for me during the day, and a couple of insanely bright light-bulb moments. Chronologically:

Ian Robinson's discussion of media types during his Atom and AtomPub talk, characterised by a slide entitled "You've Chosen application/xml, you b*st*rd." Ian laid out the notion of preferring hypermedia types over non-hypermedia types (e.g. prefer xhtml over xml) because they enable further processing without resorting to specialised dispatchers. For example, if you get an Atom representation, then you automatically understand (globally) how to interpret the atom:link links within; with a custom hypermedia type (for Ian, Savas and me writing a Web book, this is application/restbucks+xml) you automatically understand (within the Restbucks context) how to interpret links; but for application/xml you have no idea how to extract hypermedia controls unless you have some prior knowledge of the schema. Genius.

Steve Vinoski's YAWS and Erlang talk was marked by its simplicity. Steve didn't try to give us enough Erlang, YAWS, and REST to understand the whole picture, but enough from each to get us going for simpler applications. I felt that I could get a simple Erlang Web project off the ground after just an hour of Steve's time, which was marvelous.

Leonard Richardson gave a hilarious and timely talk on his real-world experiences of building RESTful services. As you'd expect it was all good stuff, but what really caught my attention was Leonard's taxonomy for services:

  • Level 0 - One URI one HTTP method - e.g. SOAP
  • Level 1 - Many URIs, one HTTP method  - e.g. most RESTful services that aren't (still loved, because people love URIs)
  • Level 2 - Many URIs, each with multiple HTTP methods - e.g. Amazon S3
  • Level 3 - Resources describe their own capabilities and interconnections - e.g. AtomPub

What Leonard's effectively saying is that you can judge the maturity of a service crudely, by seeing how far it goes up the stack: URI->HTTP->Hypermedia which is a really useful mental framework.

All the slides will appear on the InfoQ site in the near future, as will the talks since they were all caught on video. Until then I've capture stream-of-consciousness style set of reports (inspired by Stefan Tilkov's raw unedited notes format) which will be appearing here shortly.

Comments:
#

Hey Jim, 

I would argue that in the instance you are namespacing your XML, the use of application/xml is no worse than using a custom MIME type? They are just different ways of specifying the semantic context that informs clients how you have implemented hypertext.. 

cheers 

Julian

#

The processing model for a programmable-Web-friendly media type will help you identify hypermedia controls and understand what operations are supported by resources of that type. “application/xml” does neither of these things: it simply says that you can expect to receive a representation that can be treated as XML. 

Such schema-dependent representations (whether specified with XML schema or not) must be supplemented with an out-of-band processing model – usually in the form of documentation – in order to be treated as good hypermedia constructs. Whereas if you’re dispatching on media type, all you need know about hypermedia controls and supported operations is contained in the media type specification itself, against which you can build a generic client. The specification won’t necessarily dictate anything else about structure. “application/atom+xml” as covered by the Atom Syndication Format and the Atom Publishing Protocol, for example, does specify some structure for feeds and entities, but because of its generous “must ignore” processing model, you can expect to see Atom representations that differ widely in their structure. Ditto “application/xhtml+xml”.  

“application/restbucks+xml” might only specify in rather general terms what Restbuck’s domain representations look like – just so long as it tells us how to find and interpret hypermedia controls, and what operations are supported in general by resources of that type. We might then choose to delegate other structural concerns to XML schema. So media type for helping tune the hypermedia engine, schema for structure. 

It might seem a little academic to pull out custom media types in this way, but I believe it better enforces the separation of concerns between application and resource state. 

Regards 

ian

#

Ah - a very good point. Thanks Ian

#

Any document you retrieve which is application/xml can have namespaces embedded and may even point you RESTfully to a schema location, making it possible to discover new ways of extracting metadata. 

But in the real world, having no prior knowledge of a schema or media type usually renders the content useless. 

IMHO, the Link header is wildly underrated. It adds the possibility to define relationships between resources without having to embed them in any representation. An image could link to its creative commons license. A web page could link to an editable resource. The links would be discoverable without having to understand the content. 

This might make "how to extract hypermedia controls" pretty standard, for a lot of links.

#

Hey Erik, 

I'd agree with you about link headers - they very much decouple hypermedia controls from resource state for any representation type. 

Ian's taking this a step further, and saying that if you know a hypermedia type, a generic client can make progress through a state machine without resorting to out of band means. In turn this leads to lower coupling between client and service. 

Hence "media type for helping tune the hypermedia engine, schema for structure" which is my new mantra :-) 

Jim

Author Name:
Email:
Author URL:
Comment:
Antispam:
Please type the following string (note that if the strings don't match, your comment will be lost... sorry!): 'QDNJI'.
 
Recent entries

Recent comments

Feeds:
RSS 2.0 Atom