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?
Take a look at some of these to get better idea.
Facebook Graph API - https://developers.facebook.com/docs/reference/api/
Twitter Web API - https://dev.twitter.com/docs/api/1.1
The Consumer Story
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.
This post might help in integrating Facebook login into your website.
The Middle Managers
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.
Other examples include the likes of Apigee and Mashery.
WEB API is an emerging and hot trend, but it is quite simple to understand, isn’t it?
I would be happy to receive any questions/comments on this topic.