Hi Chris, 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) says<http://twitter.com/timbray/statuses/1396042066>he " *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: http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/ops/start 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). Sam On Thu, Apr 16, 2009 at 11:32 AM, Chris Webb <chris.webb@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:
http://www.ogf.org/OGF25/materials/1567/OpenNebula.pdf
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 complete 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:
http://www.elastichosts.com/blog/2009/01/01/designing-a-great-http-api/
and some more general points in a submission to the working group for cloud infrastructure API standardization at OGF25:
http://www.elastichosts.com/blog/2009/03/03/cloud-api-standardization-at-ogf...
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 date and some of the major issues.
Cheers,
Chris. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg