ElasticHosts Releases Exensive API

[Reuven Cohen]

Richard Davis, over at Elastic Hosts in the UK has sent me details of
their latest API release for the Elastic Hosts Cloud infrastructure
service. Davies noted that they feel the API semantics are more
important than syntax - and went on to say they intend to produce
text/plain, application/xml, application/json and
application/x-www-form-urlencoded variants of this same set of
commands so that users can pick whichever seems easiest. (I should
also note we use a similar approach with the Enomaly ECP API) They
seem to put a lot of emphasis on the API, I guess we'll see if
customers embrace their use of a extensive ReSTful API.

Here are some more details of the release;

ElasticHosts, the second European cloud infrastructure and the world's
first public cloud based upon KVM*, today released its API and remote
management tool. These enable users to automatically upload server
images and control servers running within ElasticHosts' flexible
infrastructure, supplementing the existing web management interface.

ElasticHosts provides flexible server capacity in the UK for scalable
web hosting and on-demand burst computing uses such as
development/test, batch compute, overflow capacity and disaster
recovery.
The ElasticHosts HTTP API is described in detail at:

http://www.elastichosts.com/products/api

The API is implemented in a straightforward ReST style, and is
accompanied by a simple command line tool enabling Unix users to
control ElasticHosts infrastructure from their own scripts without
writing any code.

--
--

Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
blog > www.elasticvapor.com
-
Open Source Cloud Computing > www.enomaly.com

[Richard Davies]

Following up our API release, we've blogged about the design
principles which we followed with our API, and why these are
important.

As interoperability and standardization efforts such as this forum
work towards designing standard interfaces for cloud computing, we
believe that these same design principles should be kept in mind -
let's make sure that we as a community produce standards which are
simple, powerful and easy to use and implement.

Happy New Year to you all!

Richard

--
Richard Davies
CEO, ElasticHosts Ltd
www.elastichosts.com

=====================
[Taken from http://www.elastichosts.com/blog/2009/01/01/designing-a-great-http-api/
]

Designing a great HTTP API — why heavyweight XML is not the answer

ElasticHosts recently released our HTTP API. In the course of system
integration for our products, evaluating our competitors’ APIs and
designing our own, we came to a clear view on what makes a great HTTP
or web services API. Like many things in computing, it comes down to
KISS: Keep It Simple, Stupid — simple for the users, that is!


SIMPLE SYNTAX

Simple syntax means making it easy for any user with a standard tool
to call the API. If you can’t call the API with curl from a single
line of shell then your API is not good enough. This rules out many of
today’s cumbersome XML-RPC and SOAP APIs, although you will want XML
as an option for users who are using XML-friendly languages.

We believe in:

* Choice of syntax: Different users will find different syntax most
natural. At the unix shell, space-deliminated text rules. From
Javascript, you’ll want JSON. From Java, you may want XML. Some tools
parse x-www-form-encoded data nicely. A great HTTP API makes every
command available with data in all of these formats for all of these
users, specified with either different URLs or MIME content types.
(OK, we admit that we’ve only released text/plain ourselves so far,
but the rest are coming very soon!).

* Don’t reinvent the wheel: Smart people designed the internet. There
are good existing mechanisms for security (e.g. SSL/TLS),
authentication (e.g. HTTP auth), error codes (e.g. HTTP status codes),
etc. Use them, and don’t invent your own, unlike one UK payment
gateway who invented a simple XOR encryption which is vulnerable to a
known plaintext attack and didn’t fix it when we pointed this out!


SIMPLE SEMANTICS

Simple semantics means having a small number of powerful, orthogonal
commands. If your API needs a 300 page document to explain it then
something is wrong. Equally, your users shouldn’t even be aware of the
artificial abstractions and data structures which you invented inside
your software.

We believe in:

* Few powerful orthogonal commands: For your API users, each call adds
overhead, both in code and response times. Produce a few powerful
calls which do the work of many smaller ones. In our case, our API has
a single call for “server create”, where this would take many calls
with some of our competitors’ APIs: starting the server, associating a
static IP, associating persistent storage, etc.

* No artificial abstractions: API users don’t care how you wrote your
software, and shouldn’t have to know or change their calls when you
change your design. Try as hard as you can to hide your internal
structures from the user unless it’s absolutely necessary to expose
them. In our case, a cloud infrastructure platform provides virtual
server hardware, and we let users configure this as they would real
hardware, choosing an amount of RAM, specifying which hard disk is on
which IDE bus, etc. We don’t invent “instance types” and we deal with
mapping the well-known hardware descriptions to how the virtualization
platform sees them.

* Immediate response where possible: All of our API commands are
synchronous, and they usually complete within seconds of all input
data arriving. If we can do this for a cloud infrastructure platform,
then surely you can for your application?


Happy New Year, and may your 2009 APIs be good ones!

[Reuven Cohen]

Richard, we look forward to having you and ElasticHosts part of the discussion. I hope you will be able to join us in New York this March.

reuven