Basics of API
Updated: Nov 15, 2020
The best way to describe what an API is, is to use analogies; so please bear with me.
Humans communicate with computers (pushing the SEND button to send a mail, which the computer does), the same way computers communicate with humans (sending you a notification of a new email, or showing you a Word document when you launch it). Humans communicate with other humans, so why can't computers communicate with other computers/systems/servers?... now, this is the concept of APIs.
API is the acronym for Application Programming Interface (also sometimes referred to as "interface" or "service"). It is a way for your phone to automatically check the weather or latest world news and display on your screen, without you creating & owning a database of the weather or the latest news. This means that your system communicated with other computers/systems/servers using an API to get this information and returned that information to you.
Why are APIs important?
To explain this, I will first have to describe two forms of software architectures, Monolithic and Micro-services architecture.
A Monolithic Architecture: is when you build a user interface (also called front-end) to directly communicate with a database that you own. This is the old way of building software due to the inflexibility and difficulty in maintaining such systems. If the system has a fault, developers would have to shutdown the front-end and back-end (database) to investigate where the problem is coming from and fix this problem. It's like shutting down a whole building because a toilet is leaking-- a bit of an overreaction isn't it?! Worse still, you can't use your neighbour's toilet in the interim.
A Micro-services Architecture: this is the answer to the above problem. Rather than join the front-end to the back-end, link them using APIs. This makes it easy to identify where the problem is, and breaks the interaction between front-end and back-end into smaller chunks. The main and most important benefit is the ability to share information in your database with external people (in Enterprise Architecture, it is referred to as boundaryless information sharing). So even if your toilet is faulty, you can use your neighbours'. This bridge is connected to an endpoint, which sends requests to the server (yours or someone else's) and receives a response in a format that you want. You can then display the received message on the user interface (front-end).
What's all this gibberish?
Imagine you want to create an Address Form on a user interface for your users to enter their home address. As a smart BA/PO that cares about Data Integrity and great User Experience, you decide to eliminate manual data entry so that the user can only enter their postcode into the user interface, and hit Enter, to enable the system to find addresses linked to the postcode and return them to the user, so they can select their address. Easy peasy? Not with a monolith.
If you are creating a monolith, the data team would have to populate the database with all addresses in the UK , then they would constantly update the database when new addresses exist. (I'm cringing at the thought of this!).
The developers would search for an API that can do this, so all the developers have to do is make a secure call to that API, and return the answers to the user. Simple!
Where did the API get the data from?
APIs are owned by other people/organisations. You could decide to create a database of all car number plates and the car's description, after which you then create an API that would link to this database. You could even sell your endpoint/API to anyone interested in searching your database for car number plates. Which means that if Google is creating a software that returns the description of a car when the number plate is searched for, all Google has to do is pay to use your endpoint/service/interface/API.
In my next post, I will teach how you can specify an API.