Cloud Computing Use Cases Whitepaper V2 - Levels of APIs

[drus...@ca.ibm.com]

As we all are seeing there continues to be discussions on how best to
implement Cloud Computing, however, in order to access a cloud
service, one must connect through an interface. It is important to
understand the various levels of interfaces from the developer’s
perspective. To start a dialogue, as part of the Cloud Computing Use
Cases White Paper V2 ( http://bit.ly/vB2es ), we have documented four
different levels of APIs:

Level 1 - The Wire. At this level I'm invoking cloud services by
building the REST URLs, HTTP headers and SOAP envelopes, and I'm
processing the responses by examining the HTTP response codes and
parsing the JSON or XML that comes back. I don't think anybody does
SOAP this way anymore, and it's probably (hopefully) not common in the
REST world either.

Level 2 - Language-specific APIs for REST and SOAP. I'm still thinking
in terms of REST URLs, HTTP headers, SOAP envelopes, etc., but I'm
working with them through abstractions and convenience methods. I
think of something like Apache Axis or Zend's combination of SimpleXML
and Zend_Http_Client here. (Those of you who have experience with
Azure, Ruby, etc., please shout out. There are lots of similar
libraries for other languages and systems.)

Level 3 - Service-specific APIs. Now I'm working with objects that
abstract away the details of REST and SOAP altogether. I'm working
with objects like buckets or VMs or files; I'm not thinking about
response codes or header fields. I'm much closer to the ideal of
focusing on business logic here, but the objects I'm using only work
with a particular cloud service.

Level 4 - Service-neutral APIs. This builds on level 3, but the
objects have removed any details specific to a particular cloud
service. At its most primitive, defining a service-neutral API starts
with some number of similar services and defines an API that's simply
the lowest common denominator of the features those services provide.
A more sophisticated effort attempts to raise the bar by defining an
API that offers a more robust set of features, allowing individual
service providers to enhance their products or write adapters to
support those features as necessary.

In a perfect world, developer productivity is highest at Level 4. That
means that the service-neutral API is powerful enough to accomplish
most tasks and implemented widely enough to work with most services.
Working with higher-level objects means the developer focuses on the
task at hand instead of thinking about the details of REST or SOAP.

On a personal note, I think it will be interesting to see how/if
higher-level APIs mask the style (REST or SOAP) of the underlying
service.

What do you think? How many of you are using toolkits or libraries
that fit into level 3 or 4? Is there enough difference between levels
1 and 2 to merit a separate discussion? Looking forward to your
thoughts as part of the Use Cases White Paper discussion ( http://bit.ly/vB2es
).

[Rob84nl]

For effective, internet-scale 'Cloud services' - whatever that means -
it is just like Web Services, please do not (ab)use terminology, you
will need RESTful services to provide the necessary massive-scale
interoperability. SOAP-based implementations with WSDL an the other WS-
* specifications cannot provide this.

On 29 sep, 22:29, "druss...@ca.ibm.com" <druss...@ca.ibm.com> wrote:
> As we all are seeing there continues to be discussions on how best to
> implement Cloud Computing, however, in order to access a cloud
> service, one must connect through an interface. It is important to
> understand the various levels of interfaces from the developer’s
> perspective. To start a dialogue, as part of the Cloud Computing Use

> Cases White Paper V2 (http://bit.ly/vB2es), we have documented four