FREE MOBILE CLOUD COMPUTING CONCEPTS
API, an abbreviation of application program interface,
is a set of routines, protocols, and tools for building software
applications. A good API makes
it easier to develop a program by providing all the building blocks. A
programmer then puts the blocks together.
Most operating environments, such as MS-Windows, provide an API so that programmers can
write applications consistent with the operating environment. Although APIs are designed for programmers, they are ultimately
good for users because they guarantee that all programs using a common API will
have similar interfaces.
This makes it easier for users to learn new programs.
MORE ON WHAT'S API STAND FOR:
Stands for "Application Program Interface," though it is sometimes referred to as an "Application Programming
An API is a set
of commands, functions, and protocols which programmers can use when building software for a specific operating system.
The API allows programmers to use predefined functions to interact with the
operating system, instead of writing them from scratch.
All computer operating systems, such as Windows, Unix, and the Mac OS, provide an application
program interface for programmers. APIs are also used by video game consoles and other hardware devices that can run software
programs. While the API makes the programmer's job easier, it also benefits the end user, since it ensures all programs using the same API will have a similar user interface.
Simple Easy Cloud APIs...it's important!
APIs are critical to cloud computing services, regardless of whether they're
public, private, or hybrid. However, most developers don't consider how their APIs should work; as a consequence, many otherwise
solid clouds don't provide good programmatic access.
This applies to those creating private, community, and hybrid
clouds for the enterprise, as well as full-blown public cloud providers.
All clouds and cloud APIs are very different, and the lack of standards
and common approaches has led to confusion around the use of APIs. The results are unproductive cloud deployments and APIs
that are changing faster to correct bad past designs than cloud managers can keep up with.
API design should focus on purpose and simplicity.
Damian Conway offers good advice
on cloud API design:
Do one thing really
Design by coding.
Evolve by subtraction.
Declarative trumps imperative.
Preserve the metadata.
Leverage the familiar.
best code is no code at all.
I boil all of this down into three key approaches.
First, simplicity leads the day. Many
APIs are built to do everything, but with such high demands placed on them, the APIs become much less useful for practical
applications. My simple rule: When in doubt, break them out. Consider a finer-grained approach.
consider performance. Often created as an afterthought, poorly performing APIs seem to be an epidemic.
Make sure to code as efficiently as you can and test, test, test.
holistically. APIs have to work and play well together, so they need common data structures and usage patterns. APIs
support systems -- they are not systems unto themselves. They need to adhere to common design patterns and supporting infrastructure,
including governance, security, and data.
Cloud APIs - they're BIG Time nowadays, with Web 2.0, for these
"things called Cloud Application Interfaces"......
Netflix beat Blockbuster using a smart API
strategy--and more companies can now do the same to undermine rivals, said cloud experts at Structure 2011 conference.
Getting well-designed and well-managed application programming interfaces
into the marketplace for developers to use may be just as important as having a corporate website, agreed a panel at the cloud-oriented
Structure 2011 show Thursday in San Francisco.
APIs are an asset to digitized content and services companies,
such as Netflix, and old bricks-and-mortar companies, such as Sears, "which is interesting; they work in both the new
economy and old economy," said Sam Ramji, VP of strategy at Apigee, a firm that hosts an API-delivery network and services.
An API is the precise
set of instructions that lets one application connect to another and interact with it, extracting services. It sounds simple,
but good, reliable APIs for different devices can be hard to build. The specific characteristics of each device must be recognized
by the API designed for the applications running on it.
Netflix last year made an API for accessing its services available
to 300 different device makers, which improved its ability to attract subscribers. Their subscriber population grew from 12 million to 20 million between January and December 31, 2010. During that period, a free
iPhone application came into existence that took advantage of the API, as well as applications for the Xbox 360 and Wii game
Netflix's main competitor, Blockbuster, filed for bankruptcy protection
on Sept. 23.
Netflix's aggressive use of APIs that extended its digitized film business model to new devices and
new customers was cited as one cause by the panel, convened to discuss "The Instrument of Cloud Monetization: The API."
Netflix had already undertaken a commitment to digitize its movies and make them available as streamed downloads
over the Internet. Anyone with an account and a PC could use the digital service. But the addition of popular consumer devices
saw the number of Netflix subscribers rise by 37%, or five
million, during the last quarter of 2010.
Century-old retailer Sears likewise made a mobile device API available for
its consumer products, resulting in the Sears2go iPhone app. Another example of an API extending the company's business is
one made available by the Disney Company to reach fans who are about to visit one of its theme parks.
Consumers using iPhone
or other device applications with an embedded Disney API can get a passport to a popular ride in the park, maps, and schedules,
and afterward post their pictures to a shared visitor site.
Having an API today for your company's products and services is
just as important as launching a website was in the year 2000. "The impact can be pretty huge," Ramji said, because
developers will be able to use to extend the company's business to new customers in ways that even the company may not foresee.
But companies that hope to take advantage of the power of an API need to make it freely available to the developers,
who will produce the application that connects a company service behind the API to some useful function for partners and customers.
Ramji made his comments at an afternoon panel at Structure 2011 in San Francisco, a cloud-oriented event sponsored
by news and analyst group GigaOm. The panel was moderated by Bernard Golden, CEO of HyperStratus, a cloud computing consulting
Golden said a successful API strategy was something like a successful open source code project. It starts
small and generates no revenue, then gains value in the marketplace through wide distribution.
Ramji, the former head of Microsoft Open Source Labs, said the analogy was apt.
panelist Randy Bias, CTO and co-founder of Cloudscaling, a private
cloud design firm, warned that if the API is only available at a price, or tends to lead application users into a sales pitch
or hidden fees, developers will shy away from it. "If the provider of the API is opaque about their intentions and their
roadmap, there's hesitancy there (to use it)," he said.
Companies posting APIs for developers to consider can encourage
their use by offering to pay developers for each transaction resulting from their application. The consumers using the application
don't necessarily know the developer is being paid, but the results can be real revenue to the developer, Ramji added.
spokesmen say using APIs is like leveraging existing assets at minimal expense. One staffer drew an analogy in his blog to
capitalizing on his house's plumbing when he added a sprinkler system for both fire suppression inside and lawn watering outside.
Most of the system was the same old plumbing, but new forms of value had been added to it.
In the past, websites
were able to extend a company's reach, provided prospective customers fired up a PC, opened a browser window, and showed up
on its specific site. An API is a more active form of customer engagement.
It extends the reach of the company
by making services available, often one or more for free, that are an enticement for a consumer visit via his or her favorite
mobile device. As the Netflix example shows, both approaches work.
But depending solely on the website and PC browser is, not a winner.....
In 1997 we attended, the first Perl Conference,
which two years later evolved into the OpenSource Convention. For us the most memorable part of the conference was a keynote given by Albert Balimoore, titled The Web is the API. At one point Andrew showed a slide with nothing on it but a UPS
tracking URL. "This is amazing," Andrew said, "every UPS package has its own homepage on the web!"
As Andrew and I both
discussed in our respective talks, that homepage wasn’t just a document that interested people could view. It was also
a chunk of data that interested machines could process.
In 1997 it was often possible, but never easy, to disentangle
that data from its surrounding HTML markup.
Fifteen years later we’ve made a lot of progress. Many cloud services are now switch-hitters.
When a person using a browser asks them to do something, they respond with HTML for humans to read and interact with. When
a computer asks — and by computer I mean a smartphone, a desktop PC, or a virtual machine running elsewhere in the cloud
— they respond with data for that computer to process.
When services switch-hit on the data side, they are providing and consuming
APIs (application programming interfaces). Many services provide APIs for smartphones, PCs, and cloud VMs (virtual machines)
to consume. This is a very good thing. But it still isn’t quite what Andrew and I had in mind, nor what Andrew meant
by The Web is the API.
Today, APIs are the API. There are APIs for Amazon, Bing, Facebook, Flickr, Google, Netflix, Tripit, Twitter, and
most of the other major web services you use. Given that bits and pieces of your personal cloud are stored in various services,
a developer may want to create an app that interacts with more than one of them on your behalf. To do that, they must learn
how to use each relevant API. Nowadays they tend to share a common set of conventions, but each API is its own protocol.
So while there’s a lot less data friction than there used to be, there’s still a lot more than there needs to be.
The data behind all
those APIs, of course, is sitting in databases of one kind or another. Can we imagine browsing those databases in the same
standard way we browse websites? Tim Berners-Lee did. In the original proposal for the World Wide Web, back in 1990, he listed a number of “future paths” including:
A server automatically
providing a hypertext view of a (for example Oracle) database, from a description of the database and a description (for example
in SQL) of the view required.
That future is real today in some places. At Netflix.com, for example, you can browse the
catalog as a switch-hitter.
Starting with Genres, for example,
you can proceed to B-Horror
Movies, one of which is “Curse of the Voodoo”, and then proceed to “Curse of the
Voodoo”‘s directors, the only one of which is Lindsay Shonteff. What you see when you click these links will depend on how your browser displays documents
written in the Atom feed format. By default most browsers display such documents in a friendly way. When you turn off that
friendly display, you’ll see the raw data document instead.
If you drill all the way down to an individual item of data, though,
you’ll get the same result either way. Lindsay Shonteff’s name, for example, has “its own homepage”
in Netflix’s web of data.
In this case the mechanism for “automatically providing a hypertext view” of the Netflix catalog is the
Open Data Protocol (OData).
It’s one way, and I think
a very good way, to make The Web is the API a true statement. Since OData is a Microsoft invention, and I work for
Microsoft, you are entitled to be skeptical. But if you’ve followed my work and interests for the past 20+ years you’ll
know that OData is the sort of technology I’ve always championed: fundamental, non-proprietary, game-changing.
Consider these two “homepages”
for “Curse of the Voodoo”:
Netflix: Curse of the Voodoo
[ odata.netflix.com/Catalog/Titles('5vSc') ]
eBay: Curse of the Voodoo
[ ebayodata.cloudapp.net/Items('190556034358') ]
The first is an item in the Netflix catalog. The second is an item on eBay.
These two webs of data are navigable in the same way. So here’s the synopsis from Netflix:
Director Lindsay Shonteff’s campy B-movie thriller centers on big-game hunter Mike Stacey (Bryant Haliday), who
finds himself on the wrong side of a tribe of vengeful lion worshippers after he kills a sacred lion during an African hunting
expedition. When the effects of the tribe’s curse begin to surface after his return to his London home, Mike realizes
that his only recourse is to return to Africa and confront the witch doctor who hexed him.
In order to correlate these two pieces of information I’ve had to learn nothing about the Netflix or eBay APIs.
I have simply navigated two webs of data, and done so in a uniform way. Whether by means of OData or some other
mechanism, I’ll want the webs of data that constitute my personal cloud to work the same way.
Search service for registered real estate
Natural language query service
Collaborative question and answer software
Ask Sponsored Listings
Search engine marketing service
Crowdsource polling service
Time zone reference service
Hosted search services
ASPECT Vocabulary Bank for Education
Education vocabulary controlled lists
Online project collaboration service
Online helpdesk tool
Associated Press Metadata
News content metadata service
Web-based E-signature service
AT&T Device Capabilities
Mobile device identification service
Location based services
AT&T mHealth Platform
Health system backend
Multimedia messaging servic
AT&T Notary Management
Digital signature service
The flexibility and
economic benefits of cloud computing have generated a tremendous amount of interest. As developers work with this technology,
an obvious concern is vendor lock-in. Writing an application that makes the most of cloud computing is great. But what if
that application locks you in to a single vendor? The Simple Cloud API is an effort by multiple cloud vendors to create a
single API that works with cloud services from multiple providers (see Resources). This article is a high-level overview of the API and its goals.
The state of the
computing promises to change IT as dramatically as anything since the rise of the Web. If you're a developer or architect,
you should at least be evaluating cloud computing if you're not using it already. These are exciting times, but the usual
caveats apply. As with any new technology, you should understand cloud computing's strengths and weaknesses and use it only
where it's appropriate.
One of the biggest risks with any new technology is building critical applications that lock you in to a particular
vendor. Cloud computing can have significant economic benefits, but if using the cloud puts you at the mercy of a vendor's
pricing strategy, that's a major concern. Even if you're perfectly happy with your cloud provider, your partners, customers
and suppliers will likely use different cloud providers. It's vital that your applications be able to work with as many providers
and services as possible.
The Simple Cloud API is designed to provide a single, simple, interoperable API for multiple cloud services and multiple
Levels of APIs
There are several ways
of writing code to work with cloud services. To put the Simple Cloud API in context, we'll look at APIs at four levels:
We'll consider these in detail next.
At this level, you are
concerned with the actual bytes that go across the connection from the application to the cloud. For a SOAP service, the application
has to build the <SOAP:Envelope> with the appropriate contents and headers. For a REST service, the application has
to create the correct HTTP headers and build a URL that contains the appropriate parameters. For example, a REST request to
the Nirvanix Internet Media File System (IMFS) to list all the items in the directory /dougtidwell might look like Listing
Listing 1. Wire format of a
sample REST request
Host: services.nirvanix.com Date: Wed, 20 Oct 2009 12:00:00 GMT
This is a request for
a list of all the folders in the directory /dougtidwell. The request includes authentication information (the sessionToken
parameter above), along with parameters like path name, page number, and page size. The complete URL in Listing 1 would include
A language-specific toolkit provides convenience
classes to create the SOAP and REST data structures. As a developer, you are still focused on the data structures that pass
between your application and the cloud, you don't have to create the data structures directly. For example, the Zend_Soap
library contains classes to simplify invoking a SOAP service. Invoking a SOAP service looks something like Listing 2.
Calling a SOAP service with Zend_Soap_Client
In both of these examples, the application isn't concerned with
parsing XML or checking HTTP return codes or similar issues; the toolkits handle most of the details. On the other hand, the
application is not focused on business objects.
At this level, you are focused on business objects. Using higher-level objects that encapsulate cloud services means
you no longer have to think about the format of the data on the wire. Working at this level, you have no idea whether the
underlying service is SOAP or REST; you simply invoke the service. Two examples of service-specific toolkits are the Zend
Framework classes for Nirvanix and Amazon S3. Following is the method for listing all of the items in a Nirvanix directory.
Listing 4. Listing all the
items in a Nirvanix directory
Nirvanix provides a
number of services. The example here uses IMFS. Calling the getService() method returns an object you can use to interact
with a particular service. Passing parameters to the ListFolder method returns an array of the items in the folder.
In contrast to Nirvanix's
directory structure, Amazon's S3 uses buckets. Buckets cannot contain other buckets, so the hierarchical structure of the
Nirvanix file system isn't supported. The simpler data model of S3 is reflected in the code for listing all of the items in
an S3 bucket.
Listing 5. Listing all the
items in an S3 bucket
$s3 = new Zend_Service_Amazon_S3($accessKey, $secretKey); $stuff = $s3->getObjectsByBucket($bucketName);
This sample code retrieves
the meta information about all the items in a particular bucket. The array $stuff has metadata about each of those items,
such as the item's name, size, content type, and timestamp.
Service-specific toolkits improve developer productivity. However, a service-specific API locks you in to a particular
service and provider. The goal of the Simple Cloud API is to provide a set of high-level classes that let you write one piece
of code that can work with multiple services and providers. In looking at the Nirvanix and S3 classes, listing the contents
of a directory or bucket required the ListFolder() and getObjectsByBucket() methods, respectively. In the Simple Cloud API,
the ListItems() method does the job for both services.
The Simple Cloud
Simple Cloud API is designed for interoperable code. Operations defined in the Simple Cloud API are supported by many cloud
services. The ultimate goal is that the code written to work with one cloud service should work with all similar cloud services.
The PHP implementation of the Simple Cloud API uses the Factory and Adapter design patterns. To work with a particular cloud
service, you call the appropriate factory method (such as Zend_Cloud_Storage_Factory for file storage) with an array of configuration
parameters. The class returned by the factory method is an adapter to a particular cloud service. The adapter maps the Simple
Cloud API calls to the service-specific calls required by each cloud provider.
The Simple Cloud API is defined for three types of cloud services:
storage refers to traditional cloud storage systems like S3 and Nirvanix. With a file storage service, you're responsible
for knowing what data you have stored in the cloud. You can get a list of directories/buckets and a list of the files in each,
but it's up to you to keep track of what each file represents. Typical methods in this API are fetchItem(), listItems(), deleteItem(),
Document storage includes more-structured systems, such as Amazon's SimpleDB. Unlike
simple file storage, document storage provides query facilities to help you find information. In some cases, the underlying
service will be a relational database with schema support. In other cases, it will be a much simpler type of service. Typical
methods in this API are listCollections(), listDocuments(), insertDocument(), and query().
queues are queueing systems like Amazon's Simple Queue Service. Typical methods for the simple queue API include sendMessage(),
listQueues(), and peekMessage().
A simple sample
Note: The Simple Cloud API is still a work in progress, and details are
subject to change. The sample application here works with the adapters for Amazon S3 and Nirvanix IMFS as of the date of this
To illustrate the interoperability provided by the Simple Cloud API, we'll build a simple
PHP page that works with Amazon S3 and Nirvanix IMFS. The code begins by using the Zend_Config_Ini class to create an array
of credentials from an .ini file. (The factory classes in the Simple Cloud API require an array of credentials as a parameter.)
The two configuration files used in this sample are s3.ini and nirvanix.ini. If the name of a configuration file is not passed
as a parameter, the code uses s3.ini by default.
Listing 6. Creating an array
require_once 'Zend/Cloud/Storage/Factory.php'; require_once 'Zend/Http/Client/Adapter/Socket.php';
require_once 'Zend/Config/Ini.php'; if (array_key_exists('configfile', $_POST)) $configFile = $_POST['configfile']; else
$configFile = '../conf/s3.ini'; $credentials = new Zend_Config_Ini($configFile);
The sample configuration
file for an Amazon S3 adapter looks like Listing 7.
value is the name of the PHP class that implements the StorageService interface. For S3, the class is Zend_Cloud_Storage_Adapter_S3.
A Nirvanix configuration file requires an application name (currently represented by the parameter auth_accesskey) and a directory
name, in addition to a username and password.
Using the default configuration
file means that the information from s3.ini is used. That displays the contents of the S3 bucket named in the configuration
Figure 1. Bucket or directory
listing with default configuration file
The bottom of the screen has two buttons that let you reload the page with a particular configuration file. Clicking
on Create adapter using nirvanix.ini runs the exact same code, but with different configuration parameters.
The results display the contents of the Nirvanix directory named in the configuration file.
Figure 2. Bucket or directory
listing with a different configuration file
These two sets of results were generated by the exact same line of code. The configuration file changed, but the
application itself did not.
The Simple Cloud API is a cooperative effort of several major cloud
vendors to create a single, simple, interoperable API that works with many cloud services and providers. Work is under way
to add support for more cloud services and cloud providers, and implementations of the API in languages other than PHP are
in progress, as well. Cloud computing won't reach its full potential without openness and flexibility. The Simple Cloud API
is an important tool for keeping the cloud open and your applications flexible.