Well defined REST API’s are fully capable of providing the separation of model and protocol you are decrying the lack of. For a practical example of this see Atom. The model is defined by the Atom Feed Spec and the protocol is defined by the Atom Publishing Protocol Spec. The IETF clearly understands the difference between model and protocol – let’s hope the DMTF does as well.

This goes back to REST basics, the model is the hypertext representations and their links – a protocol is the specifics of how HTTP is used to interact with this hypertext. You could define some other protocol for interacting with the hypertext. For instance, you could define a WS* protocol for interacting with Atom resources – it would define some mapping of ‘logical’ hypertext operations to some specific WSDL interface. The beauty of HTTP is that its entire role in life is to supply such a mapping.

So, if vCloud were to be well documented, it would emulate the example of Atom and specify its model and publishing protocol as separate elements. To be fair, it isn’t too difficult to tease this out of the current vCloud Programmers Doc but you are right to note that those how intermingle model and protocol in the name of REST are making a mistake. Users of the API (and programmer docs) don’t have to make this distinction; however, formal definitions of REST APIs should.

Thanks for another enthralling post. We agree on pretty much every point… especially about HTTP as the “universal interface”. I jumped on OCCI during the formation discussions (it was called CAPI at the time) and had a clear vision of how it could/should/would look. My plan was to follow in the footsteps of Google GData (at least v2) by taking advantage of AtomPub as the meta-model. It has links and categories which are very nice, and as a bonus “link relations” are already part of HTTP and HTML too. Atom’s categories are also quite cool (no forcing people to use fugly terms like “VPDC”) but they didn’t work outside of Atom so I wrote an I-D (Web Categories, heavily inspired by Web Linking) to bring them to HTTP and will see about something similar for HTML in due course (assuming we include a HTML rendering, which I would like for us mere mortals – thus combining the machine and user interfaces). The theme is to be as compliant with existing [mostly IETF] standards as possible, contributing to them where we can (in addition to IETF I’m in the HTML 5 WG and have been keeping a close eye on those developments too, if not contributing to them).

I had originally argued for a tight schedule, bringing the due date in from 2011 to this year – after all there was little do do (see the GData specs which cover, what, 16 different data types from contacts to calendars to documents, blogs and videos for proof). Fortunately or unfortunately I ran into problems gaining consensus regarding Atom, XML, or indeed any one particular format. Perhaps I didn’t do a good enough job of explaining but then again with numerous people flat out refusing to touch anything but their preferred format I wonder how successful any protocol based on XML/JSON/etc. will ever be. We’ve been forced to separate the model from the protocol as a result, though we are avoiding going for a pure “model then render” type approach that can result in a domain-specific language with a steep learning curve. Instead we are relying on existing standards like HTTP as a meta-model where we can. For example the web is built on linking so why would we want to reinvent the wheel? Indeed HTTP included linking functionality from the outset (Link: headers and poorly specified LINK and UNLINK verbs) but its thunder was stolen [for a few decades] by hypertext (eg HTML) with its in-band linking. Link relations and [Ss]emantic web technologies (like RDFa) are now enabling us to link anything to anything in a standard rather than home-grown fashion which is IMO a good (and necessary) thing for cloud computing. We’ll be doing our best to use these standard approaches to associating and linking resources.

Basically the idea is to accept the various formats-du-jour (OVF, VMX, Xen, Hyper-V) and add metadata for linking (e.g. associating storage, compute and network resources with one another), related resources (documentation, console access/screenshots), categorisation (with a flexible, proven categorisation model lifted directly from Atom) and of course animation (start, stop, restart, resize). This metadata will be exposed out-of-band, either in the HTTP headers or a separate metadata resource (or both), which allows us to cater for any format (including non-hypertext formats like machine images) – rather than relying on any one in particular (e.g. OVF). Nobody bestowed a particular image format as “the one” for the Internet and now we have both choice (jpeg for pictures, png for logs, etc.) and interoperability (browsers support a number of common formats). The question came up again in the context of video codecs and despite being a free software advocate I’m happy to see that neither commercial nor free formats got a leg up here – markets are good at deciding such things.

Anyway I’m working [almost] 24×7 on this now and canceled a family trip this week to get it finished as soon as possible. Following much discussion we now have a clean and simple protocol that I should have documented for public comment directly. Watch this space.

Sam