APIs 101: What is an API, and where would we be without them?
Hi! This is part one of a series introducing (REST) APIs: what they are, what they do, and how to use them. This first part introduces the concept of an API, and provides context for how they help organizations exchange data cleanly, reliably, and securely. Later installments will discuss how APIs are used in practice, and give examples of what can be done with them.
What is an API, anyway?
It's okay, this was all of us at one point
Put simply, an Application Programming Interface (API) is a software interface that enables two computer programs to exchange information. There have been APIs of one type or another for as long as there have been networked computers, but these days, most people say "API" to refer to a specific type of API called a Representational State Transfer (REST) API.
...which is both true, and a statement that is so generic that it doesn't really impart much. It's like saying that Seinfeld was "an influential sitcom"; REST APIs (hereafter I'll just refer to them as "APIs") are so much a part of the landscape now that it's hard to grasp how much of a game-changer they really were. To better understand what an API is, then, it's helpful to better understand...
Life Without (REST) APIs
Computers are incredibly useful, powerful machines, but are limited in what they can do in isolation. The secret sauce is in networking - that is, connecting different computers together to handle different pieces of a complex workload.
In the wild west of early computing, computers received input using physical media like punch cards, which could only be encoded once and were prone to damage (or, dog forbid, someone dropping a deck that would then need to be resorted into the correct order). Even once computers could talk directly to each other, there was still no standard way to store or share data between systems, so custom programming was often needed to bridge the gap between incompatible formats. This process was, as one might imagine, tedious, error-prone, and difficult if not impossible to scale.
To put this in perspective, imagine going to a fast-food restaurant. The process for ordering food is simple:
- Look at a menu of available options
- Walk to a counter and order from the menu (or punch in your order at a touch-screen)
- Pay
- Tasty food appears
No matter where you go, the experience is consistent, as well as being mostly hands-off for you, aside from choosing what you want to eat.
The food is also the same. If I order a Big Mac and fries in Boston, it will be the same Big Mac experience as if I order in San Diego or Helsinki.
Now imagine the same restaurant...but there's no menu, no counter, and no guidance. There are ingredients around, but no recipes to tell you what to do with them. You might piece together something edible, but maybe you didn't know the right proportions for the secret sauce, or the right temperature for the grill.
And even if you do figure out a semi-good, not-sad meal, what happens if you go to the same place next time and the walk-in has been rearranged, or ingredients swapped out? You'd have to figure out all over again where everything is, and you still don't know how to make the secret sauce.
From the restaurant's perspective, this is also a nightmare: customers wandering around in the kitchen willy-nilly, leaving dirty dishes and spills, wasting or contaminating ingredients... it's no way to run a business.
This pre-API chaos is what early inter-computer communication felt like. Everyone had ingredients, but no shared recipe - just lots of sad food and burned fingers.
That’s why (REST) APIs were revolutionary: they gave everyone the same menu, counter, and prep instructions. Suddenly, systems could work together quickly, efficiently, scalably, and without trashing the kitchen.
Next time, on API Masterpiece Theater: what does a REST API actually look like? What can I do with it? And did Lassie ever get Timmy out of that well?
Stay tuned for the next installment!