Explained Simply -APIs
Part 2: Why APIs exist
Builds on: Part 1 showed that an API is the waiter between your app and another system.
Leads to: What kinds of APIs are there?
Single idea: APIs exist so that connecting two pieces of software doesn’t mean building one of them from scratch.
Last time, we saw that an API is the waiter who takes your order to the kitchen. But why do we need a waiter at all? Let’s imagine the restaurant without one.
Life before APIs
Suppose you run a travel app and want to show the weather for a trip. Before APIs were common, you had a few options. You could build your own weather stations. You could ask someone at the weather company to email you a spreadsheet every morning. Or you could write a program that reads their web page and hopes the layout never changes.
Each option worked for a while, but none of them scaled. Every new partner needed its own custom arrangement, its own format, and its own repair job whenever something changed on either side.
Everyday comparison: Think of a restaurant that buys ingredients from ten suppliers. With no standard order form, the chef has to phone each supplier, speak their particular way of describing things, and check every delivery by hand. Adding one more supplier means learning one more phone routine.
The problem grows fast
If every app connects to every service in its own custom way, each pair needs separate work. Ten apps and ten services can become a tangle of one-off connections that nobody wants to touch.
What APIs changed
Get ThinkTaught’s stories in your inbox
Join Medium for free to get updates from this writer.
An API gives each service one published menu. Anyone who wants the service learns to order from that menu, and that’s it. This changes three things:
- Shared rules. Everyone agrees on how to ask and how to answer.
- Control. The service decides exactly what outsiders can see and do, and can change those rules when needed.
- Independence. The kitchen can change how it cooks, as long as the menu stays the same.
A quick example of the old way
Before APIs, one common trick was called “scraping”: a program reads a web page and pulls out the numbers it wants. It works until the website changes its layout, and then the program breaks without warning. An API is a deliberate promise: here is the menu, and we’ll keep it stable.
Where you see this today
When a shop lets you pay with your bank, the shop never got inside the bank’s systems. The bank published a menu for payments, and the shop ordered from it. The same idea sits behind a weather app, a delivery map, and “Sign in with Google.”
Quick recap
- Before APIs, every connection between two systems was a custom job.
- Custom connections multiply quickly and break easily.
- An API is a published, stable menu that makes connections repeatable.
- The service stays in control of what it shares.
One question to take with you
We now know why APIs exist: they replace one-off connections with a standard menu. But not all menus are the same. Some APIs serve data over the internet, some live inside a library you install, and some are built into your operating system. What kinds of APIs are there, and when would you use each one?
That’s what the next episode answers: Kinds of APIs.
Follow ThinkTaught so you don’t miss it. If something here is unclear, tell me in the comments. We’re learning this together.
