Monthly Archives

May 2017

API + RESTful API. An introduction. Plain and simple

By | Others | No Comments

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 to 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)

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.


My attempt was to only provide a plain and simple outline to API and RESTful API. There is a lot more in it and the world wide web should be your best guide.

May the POST be with you!
And May is hot!

Further reading:


O’Reilly,

Restful Web APIs https://www.amazon.in/dp/9351102971/ref=cm_sw_r_cp_apa_i_2A0fzbJN3CK5T


Eko ties up with Prabhu Money to Boost Money Remittance Business to Nepal

By | Others | No Comments

Eko has expanded its Indo-Nepal remittance (money transfer) services in partnership with Prabhu Money Transfer. Through these integrations, Eko enables it’s agents to remit money to a wider audience in Nepal. Eko’s first international tie-up for remittance services was with Nepal’s Prabhu Money Group in 2016. The service will benefit 30 lakh Nepali migrants living across India.

WhatsApp Image 2017-05-13 at 12.04.12 PM

The service enables Indian and Nepali citizens living in India to send money to their dear ones in Nepal, and the recipient can avail the cash “instantly”. Citizens of both the countries can use the remittance service in the form of cash to cash, cash to bank account, cash to co-operative bank account and through top-up remittance cards. Eko has an India wide network of retail agent outlets that provide various financial services to customers. For using the Indo-Nepal service, users need to provide their KYC to an Eko retail agent. The remitter needs to provide his Indian or Nepali identity proof, while the recipient needs to show his identity proof in Nepal to receive the cash (in case of cash to cash transfer).

Abhishek Sinha, cofounder and chief executive officer, Eko shared, “This expansion is another big achievement for Eko. Millions of Nepali citizens move to India for better career opportunities and to earn their livelihood. Sending money to their families in Nepal has always been a major challenge for them. This service will help Indo–Nepal migrants remit money to their loved ones in a faster, easier and secure way, and will also add to the revenue opportunity for Eko agents and distribution partners. This is yet another milestone in our journey towards establishing international tie-ups for money remittance.

He further added “Indo-Nepal remittance business is estimated to grow to rupees 200 crore per annum and we look forward to capture the opportunity, with our expertise in remittance business, our India wide network of Eko retail agents and now a Nepal wide network of remittance disbursal agents, branches and ATMs through this partnership with Prabhu money Transfer

Till now, Eko platform has securely processed more than rupees 5.90 crore. With Eko, a remitter can do transactions of 50,000 rupees per day and is allowed up to 12 transactions in a year. A fee of 150 rupees is charged for remitting up to 30,000 rupees and 200 rupees for remitting up to 50,000.