I’m your zero
And you’re the one
Stand by me
Let’s be one
Cause when I stand
Right next to you
We both make
The perfect two
And you’re the one
Stand by me
Let’s be one
Cause when I stand
Right next to you
We both make
The perfect two
0
1
01
10
:)
Connect!
From Appliance Plumbing Interface…
Imagine that you have just designed a water faucet/ tap which dispenses water only if your fingerprint matches (however strange this may sound, I believe creativity should know no bounds ;). Now, for this to be actually used in a real wash-room or a kitchen sink, it needs to have a receptacle that exactly fits the common water pipe end-point. Lets say, it needs to have the female threaded end 1/2 inch diameter pipe to couple neatly into the male threaded pipe end. In other words, this new contraption of yours needs to follow the same plumbing interface definition as the pipes it needs to work with.
…To Application Programming Interface
Now, imagine if you were more of a software dude/ dudette than a pipe-hardware one. You might design a piece of software that will allow money from your bank to flow out only if your fingerprint matches (this sounds a lot more familiar, right? :). For this widgety creation of yours to be actually used in a real banking app or website, it needs to be able to be ‘integrated’ into the money flow interface definition of the bank(s). As a developer of this new functionality, you therefore need to follow what is called as the Application Programming Interface (API) definition exposed by the banking entity that you intend your software to work with. There you are! You have been hereby introduced to APIs. Simple right?
Why API?
The advantage of defining an API is this. Once defined, and published, it opens your platform up to a limitless set of different applications by independent innovators. So you might see some developer making an app that sends money from a bank account every time someone likes her profile pic on Facebook, or another who develops an app that makes a donation to a random NGO every time you use a swear-word on twitter…I hope you get the drift. There is no limit to the variety of innovation this can spawn. And all this while you enjoy a nice cold iced lemon tea reading some news-feed on your tab.
In short, APIs decouple application use cases, innovation, revenue generation and growth from your core platform. The better defined your APIs and the partner on-boarding processes are, the more you can relax and count the beans :)
API is also important because it helps make as much sense of the options available, to the humans implementing it as it does to the machines consuming or exposing it. This is an act of fine balance.
An API once said, “I need some REST”
Lets now focus on something a bit more technical. RESTful APIs. For a start, Restful does not refer to the relaxation that I’d mentioned a short while ago. The REST in RESTful refers to REpresentational State Transfers.
From verbs…
A lot of us have come from the functional programming world. In simple terms, the interfaces defined there would correspond to the verbs that were being exposed. For instance, in a banking app, you could have an interface defined as getBalance(account) which would return the account balance for a given account. Or, sendMoney(account1, account2). Or, listAccounts(customer). These functions could also be exposed as APIs and they do something based on its input parameters. The response of the API call would be the action defined as the verb and output parameters that would provide more details on the action done.
This kind of API has one inherent problem. An API description could be really arbitrary and it would be difficult to imagine all the functionality exposed without having explicit access to the API creator’s documentation.
…To nouns
RESTful APIs are a different breed altogether. They focus a lot more on the resources or nouns, instead of verbs. For example, ‘customer’ could be a resource, ‘account’ could be another and so on. As for the actual action that you would want to take with a resource, REST simplifies it all down to a set of pre-defined verbs in the WWW HTTP definition.
When you visit google.com, for example; the browser actually executes a GET request for the index page based on the URL (Uniform Resource Locator) http://www.google.com.
The idea (RESTful lends its origin to the doctoral thesis of a genius named Roy Fielding) is that, given these constant verbs; All that a developer needs to know is the set of objects/ nouns that he might have to deal with.
For instance, assume a simplified banking application. It may have a resource called customer or transaction or account. So, in the simplest sense, assume the base URL is https://myxyzbank. Now the base URL is like the rootdirectory for all resources (nouns). So, accessing a customer within the bank would likely be baseURL/customer.
There are a few more properties of RESTful APIs. I would only want to touch upon the fact that these API calls are also stateless. That is, a RESTful API call is in itself complete and independent of previous or future calls. In other words, the API calling entity’s state is not preserved on the server in between calls.
Singular and plural
Also noteworthy is the singular and plural use of these nouns.
While /customer/id refers to a particular customer with a given ‘id’ as its identity;
/customers/ refers to all the customers collectively.
So, executing an HTTP GET request on https://myxyzbank/customers should likely return a list of all customers within the bank, executing GET request on https://myxyzbank/customer/id would return a particular customer only. So, simple plain English “get a list of all customers in this bank” translates to an API, GET on https://myxyzbank/customers/ and the bank should spew out its long list (Of course it ain’t that simple. Security, roles, access and privileges have been excluded from the scope of this article).
Now back to the 4 main primitives and why they are pretty much sufficient for most applications.
Get, Post, Put and Delete is all you need
GET- as the name suggests would simply fetch the resource(s) identified
POST- use it when you intend to create a new resource(s) on the server
PUT- updates an existing resource on the server
DELETE- deletes the identified resource(s)
POST- use it when you intend to create a new resource(s) on the server
PUT- updates an existing resource on the server
DELETE- deletes the identified resource(s)
This sounds a lot like CRUD framework (Create, Read, Update, Delete) used for data storage.
Parameters
Additional parameters could also be passed to and from the server along with each resource request. This data could be in different formats, the most popular and elegant one around is called JSON (Java Script Object Notation). Another excessively verbose and elaborate protocol from our good ‘ol days is XML (Extensible Markup Language).
Beauty and the beast
There is a certain sense of beauty, logic, crispness and cleanness in the structure of truly RESTful API. The sad part is that most implement it with varying degrees of RESTful-ness. To the extent that I have even seen a bank call GET /getCustomerBalance as a RESTful API! That’s a verb on verb action and totally looses the plot.
