Recently, there has been a lot of buzz around WEB APIs and
developer versions of popular social networking companies like Twitter and Facebook.
There was a time when the industry was obsessed with SOA and you had to be
doing SOA to do it right. Reusability and Loose coupling were the much needed
aspects. While this is still the case, the use of Web Services to implement the
service-oriented architecture is giving way to REST-based services which are
much faster – to implement as well as to understand.

Also more and more individuals are interested in creating
their own mobile apps with the advent of platforms like Android SDK, IBM
Worklight, Phone Gap and trigger.io

REST is Representational State Transfer. It’s a protocol
based on HTTP which defines everything on the internet with a unique identifier
(state).

So for example your Facebook profile picture is also a
resource on the internet which is uniquely identified. You can GET it using a
URL, you can POST a new picture of yourself, PUT (edit) the existing picture or
DELETE the picture.

The catch is that you are not doing all this using the Facebook
page, but using URLs (or more specifically – Facebook Graph API); the advantage – you can plug this functionality
in a custom app you write.

So how does this all fit in together? Let’s put together the
pieces of this jigsaw puzzle and look at the primary actors/stake holders in
this space.

The Provider Story

The providers are the companies (or individuals) who have
built some custom functionality which is unique to them. They now want to make
it open for anyone to use. So they come up with their APIs (Application
programming Interfaces) which are on the WEB, hence called WEB APIs. Simple,
isn’t it?

The simplest to understand, consumers are simply put the
people who use the WEB APIs. So this is you and me. The consumers can also be
enterprises. We need the APIs. How else would we know how to get that much
desired resource which is lying in some corner of the Internet?

As already discussed you and I can plug-in the functionality
provided by someone else in our own app – something like a mashup.

A very common example is companies using Facebook/Gmail
credentials to let you log in to their websites and then posting content on
your timeline. You can use Facebook Graph API for this purpose.

The primary tenet is
reusability- why build something which someone has already built and is making
publically available.

WEB APIs or REST based services open the gateway for
cross-company collaboration.

You need a cab in a city which is new to you, what do you
do? Yellow Pages...

The Middle Managers are the yellow pages (intermediaries)
which collect information about multiple providers and make them available to
the consumers.

Not all companies have a wide social appeal, most are more
specific and domain-oriented. The central managers come to build the bridge
between producers and consumers which would otherwise not know each other at
all.

In addition to acting like a directory of provider WEB APIs,
middle managers may choose to provide certain value-adds to the providers –
like providing API Analytics, which help the provider improve their services,
or help know who is their primary customer base, when was the API accessed the
most, which geography this is most popular. This is indeed an upcoming trend.
This is where IBM Cast Iron Live for Web APIs comes into picture.