What is an API?
Explained in a way that everyone understands.
An API is what makes it possible for different programs and digital services to interact with each other. Wow, that sounds incredibly dull. And that’s a shame, because APIs are actually very important.
An analogy:
A few weeks ago, a message popped up on my car’s display: “Service now.” I don’t know anything about servicing cars, so I called a workshop and asked if they could do it for me. After giving them my license plate number, the conversation went something like this:
– Does June 10th work?
– Yes, that works.
– Do you need a loaner car?
– Yes, please.
– I see it’s about time for an inspection.
– Already done, no issues.
– Great, see you on the 10th.
– Thanks, bye.
Let’s say my car was a futuristic smart car that could book a service appointment on its own via, for example, an online booking system that the workshop provides. In that case, the conversation above would be handled by two programs, each with its own API. In this example, I act like an API for my car, and the person at the workshop acts like an API for the workshop.
An API contains a set of calls (questions) that a developer can make, and you usually send along several parameters (facts).
First, I make a call like “I want to service my car” and include the parameter license plate number. That call gets a response, often with parameters, in this case, “Yes, that works” and a proposed date.
But that’s not all. The “workshop API” uses the license plate parameter to make a call to another API to check whether it’s time for the car’s inspection, and gets the response “Yes, inspection is due.” The workshop API then uses that response to make another call to me and ask whether I’ve already had the car inspected.
From experience, I know that if something from the inspection needed to be fixed before a reinspection, the workshop would take care of it, without involving me at all.
And that’s how APIs work. Different systems can call each other and, in turn, make new calls to other APIs, until everything is done.
An API is simply a collection of questions that can be asked of a program or a service. If the API has good documentation, a developer can learn which questions can be asked, what parameters should be included, and what parameters can be expected in return.
However, just because an API exists doesn’t mean that different applications can automatically use it. Just like I can’t read any book in French just because French dictionaries exist, a program or service must be specifically built to use other APIs.
At Twofour, we’ve moved from “mobile first”, where mobile was at the center, to “API first,” where the API is the core. This means we develop new services starting from the API that the service will provide. The different user interfaces we build (usually a public one and one for administrators, sometimes many more), then connect to the API, whether they are mobile apps, computers, smartwatches, or even other APIs from external services.
So now you know enough about APIs to read that blog post about Jeff Bezos’ requirements, and nod along in agreement.