Mar 17, 2020
When people start talking about The Cloud and moving your data off-premise do you tune out? When considering data security are you unsure how your computer software packages interact? Need to get some data from your accounting package to your CRM without printing it out and typing it in again? Then this article is for you. Read on as APIs gallop to your rescue.
Before we go too far let’s take a first stab at defining what an API is. Knowing what those three letters stand for is a good start: Application Programming Interface. Don’t worry if you’re none the wiser for that, let’s add some analogies and an example on top which will help you visualise it.
So, a software application may receive the data that it needs (the input) from a number of sources. You’ll be familiar with typing information on the keyboard but you may also be able to import a spreadsheet of data too. An API is yet another possible method of input where a different computer program can fire a request at the application in order to add more data or to update existing data.
APIs, however, are not just one way. As well as using them to put data into an application we can also use it to get data out. In this respect it’s more like your printer or your computer monitor. The third party software will make a request for some data which your application will send back, all via the API.
Here’s a real-world analogy: If you are ordering food at a restaurant then you may view the menu and request what you want. What comes back matches your request. Think of the kitchen that prepared the meal as the third-party software application, the menu as a list of instructions that it accepts and the waiter as the API. By making a valid request (from the menu) to the API (the waiter) your request (your order) gets a response (the food) from the application (the kitchen).
So in order for these APIs to function the way that we’ve described they need to be connected to a network. Over that network the various applications can send new data or request existing data. Having an API enabled application that isn’t on the network is of no value whatsoever.
The best network is, of course, the Internet and therefore many of the APIs that we deal with today are connected to it. But that means the application can’t sit on your desktop - there’s a large security overhead to being connected to the internet and so a server is the best box for the job. You might have one humming away in the corner of your office and, yes, theoretically you could set that up as an API with your software sitting on it.
However, for a host of reasons such as security, maintenance and reliability the on-premise server is rarely a good choice for having an API. Instead people turn to servers that are housed in specialist temperature controlled, backup-powered and secure buildings with racks and racks of servers all running various applications while connected to the internet. Sometimes these applications aren’t just on one server in one building but copied and synchronised across many different geographical locations. You will know it better as the Cloud.
There’s no mystery in working with an application in the Cloud. You most likely do it all the time and access it via a web browser. When you look at train times or book a flight, you’re getting information delivered via an API. Modern technological concepts like Smart Cities and Internet of Things (IoT) rely on continuous API calls to ensure they know what’s happening and can make appropriate calculations.
APIs are configured using “endpoints”. These look just like web addresses but instead of displaying a web page they return a text response and, if appropriate, some data called a “payload”. That payload should be the answer to your query. An API is normally made up of a number of these endpoints, each of which are focused on doing a different job. Some will add data, some will return a response to a query, some will check you are authorised and return a token etc etc
The data that is returned is often in JSON format. This is an efficient, robust way of returning structured data. It’s difficult for a human to parse - although it will probably make sense if you were to view it - but can easily be manipulated and read by the receiving application.
One thing that we need to address to make sure you get a good, clear picture of APIs is security. If we have all these requests to update, add and fetch data going all over the internet then surely that’s a recipe of chaos? Yep, it would be if each of the requests was not checked to ensure that the person asking for the data or offering the new data wasn’t authorised to do so.
To this end, each API probably has some form of authentication. Not to get too detailed but when an application first speaks to another application through the API it firstly offers it’s credentials. This might be as simple as a username and password. If those credentials are accepted then the application doing the asking gets rewarded with an authorisation token. By including this token in every subsequent request both applications can be trusted, requests can be traced and it keeps the non-authorised requests out.
We need to have a common set of protocols to make sure all this works. Not only does this ensure that the billions of different applications can get questions and answers in a timely way but also to make life a little more bearable for us long suffering software developers.
So you might hear words like a REST API or oAuth authentication for the API. These are protocols that the software developer needs to know about in order to make a connection to a specific application API. So if you want to connect your application to GMail then in addition to the Gmail API documentation you’ll also need to set up an API interface that uses REST.
Even with that very lightweight grounding in what APIs are and how they plug together you’re closer than you think to actually leveraging some help through them. Although companies like ours can build and integrate custom solutions there are tools out there that you can get up and running more or less at a hobby level.
You might like to try If This Then That which is a fun little tool that connects applications that have APIs and makes them talk to each. Want to put a message on Slack when a specific email is received? Want to track your work hours in Google calendar based on your location? Assuming you’ve got an existing account then connecting them all together is easy.
At the next level you’ve got systems like Xapier which provides a single API interface for many different application types and is often a turnkey solution if you find yourself keying in the same information more than once.
Don’t be shy in factoring API connectivity into your strategic business plan or software tool. We’re available if you want some more information so feel free to get in touch.