[occi-wg] ElasticHosts introduction
samj at samj.net
Thu Apr 16 06:17:32 CDT 2009
Thanks for the intro and the useful links. I've read your "designing a great
HTTP API" post before and agree that we should not be reinventing the wheel
(e.g. rely on SSL/TLS and HTTP for auth), though I'm not sure (as in I
haven't formed an opinion) on whether we should support "choice of
syntax"/multiple formats (e.g. XML vs JSON vs ???). Tim Bray (who we'd very
much like to see get on board)
*Really [doesn't] like the JSON-*or*-XML trend. Adds work, no benefit, pick
1*". Perhaps the answer is to require one and provide for others.
Sun Cloud APIs are so far as I can tell straight from the Q-Layer
acquisition (which provided an Ajax virtual data center development tool) so
the choice of JSON was obvious. It's less obvious when your clients are
likely to be anything from simple HTTP utilities (curl/wget) to command line
tools, "thick" management clients and automated agents (MS System Center,
RightScale, etc.). Same applies when you want a standard that doesn't stifle
innovation and is thus easily and infinitely extensible, while providing a
common denominator for interoperability.
What I've done so far is based it on an extremely simple, well specified and
common XML structure (Atom - RFC 4287) and (following Sun's example)
embedded links for operations:
These links can obviously be actuated by any HTTP client and they could
obviously be embedded in a format of your choice (e.g. json).
On Thu, Apr 16, 2009 at 11:32 AM, Chris Webb <chris.webb at elastichosts.com>wrote:
> Quick intro: I'm Chris Webb, CTO of ElasticHosts, and I designed the
> ElasticHosts API (see http://www.elastichosts.com/products/api for docs)
> which has been well-received by users and integrators for its clarity and
> simplicity. See for example Ignacio's comments on ElasticHosts integration
> with OpenNebula:
> We've been discussing API standardisation with Randy Bias from GoGrid for a
> little while, and Alexis and Sam have been encouraging us to get involved
> now the OCCI group is properly underway.
> One of our key design goals was that it be possible to describe our
> API in a couple of pages, and interface to it in a couple of lines of shell
> script without proprietary tools. I strongly believe that producing an
> heavyweight, overengineered API which doesn't satisfy this aim completely
> fails end users. We wrote some thoughts on this on our website in a New
> Year's blog posting:
> and some more general points in a submission to the working group for cloud
> infrastructure API standardization at OGF25:
> We're looking forward to discussing these issues with the newly formed
> group, and I'm about to follow up on some of work the group has done to
> and some of the major issues.
> occi-wg mailing list
> occi-wg at ogf.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the occi-wg