Second post in the three-post series:
A couple of weeks ago I asked Is OCCI the HTTP of cloud computing?
I explained the limitations of HTTP in this context, which basically
stem from the fact that the payloads it transfers are opaque. That's
fine when they're [X]HTML because you can express links between
resources within the resources themselves, but what about when they're
some other format - like OVF describing a virtual machine as may well
be the case for OCCI? If I want to link between a virtual machine and
its network(s) and/or storage device(s) then I'm out of luck... I need
to either find an existing meta-model or roll my own from scratch.
That's
where Atom (or more specifically, AtomPub) comes in... in the simplest
sense it adds a light, RESTful XML layer to HTTP which you can extend
as necessary. It provides for collections (a 'feed' of multiple
resources or 'entries' in a single HTTP message) as well as a simple
meta-model for linking between resources, categorising them, etc. It
also gives some metadata relating to unique identifiers,
authors/contributors, caching information, etc., much of which can be
derived from HTTP (e.g. URL <-> Atom ID, Last-Modified <->
updated).
Although it was designed with syndication in mind, it
is a very good fit for creating APIs, as evidenced by its extensive use
in:
I'd explain in more detail but Mohanaraj Gopala Krishnan has done a great job already in his AtomPub, Beyond Blogs presentation.
The
only question that remains is whether or not this is the best we can
do... stay tuned for the answer. The biggest players in cloud computing
seem to think so (except Amazon, whose APIs predate Google's and
Microsoft's) but maybe there's an even simpler approach that's been
sitting right under our noses the whole time.