You Used Ten APIs Before Breakfast
This morning, before her first coffee was finished, Vera checked the weather on her phone, glanced at the transit map to see if the buses were running on time, and paid for the coffee by tapping her card. Three apps, ten minutes — and behind them, a good ten different APIs she never saw: each app is glue for several. Nothing on that phone did its work alone.
That is the fact this page makes visible: nearly everything an app shows you or does for you is a request to someone else's API. Once you see it, you cannot unsee it — and the word from the last page stops being abstract, because you have been surrounded by the thing it names all along.
The Weather Widget
Your phone does not measure the sky. When the weather app opens, it sends a question to a weather service's API — roughly, "what is the forecast for Riverport?" — and displays the answer it gets back. The pretty icons, the hourly graph, the rain warning: all of it is decoration drawn around a plain-text answer that arrived from a server run by a company you have probably never heard of.
The Map with the Little Buses
The transit map is the same conversation on repeat. Every few seconds, the app asks the transit authority's API where the buses are right now, and redraws the little markers from the fresh answer. The map is not watching the buses — it is a picture, redrawn over and over from repeated answers to the same question. When the markers freeze, it is almost never the buses that stopped; it is the conversation.
The Card Payment
The tap at the café is the highest-stakes call of the morning. The card terminal asks a payment provider's API one precise question — may this card pay 3.80? — and shows the answer as a green check or a red decline. The café never sees Vera's bank account; the terminal never decides anything itself. One question out, one answer back, money moved. The entire global card economy runs on that shape.
Apps Are Assembled, Not Built from Scratch
Here is the pattern behind the three stories. A typical app is glue between half a dozen APIs: one for signing in, one for maps, one for payments, one for sending you notifications. The people who built it did not write a weather service or a payment network — they read those APIs' documentation and connected to them, the exact skill this book teaches. That is why so many different apps have the same building blocks: they are, quite literally, the same blocks.
It is like a restaurant kitchen that orders in: the bread comes from a bakery, the fish from the market. The menu is the restaurant's own, but the ingredients arrive from suppliers. Apps cook with delivered ingredients — and the delivery contracts are APIs.
- "The app has all its data inside it." Mostly it has none. It fetches what it shows the moment you open it — which is exactly why airplane mode turns a rich app into an empty shell.
- "If I can see it in the app, the app made it." The app displayed it; some API produced it. Two different parties — and when the number on screen is wrong, knowing there are two parties is the first step of finding out which one to blame.
- "APIs are rare, advanced infrastructure." They are the default way software is put together. The rare thing is an app that talks to no one — and it would be a lonely, mostly useless app.
- "Which API did this come from?" is the first question behind every "why is the app showing nonsense?" — and now you know to ask it, which already puts you ahead of most of the room.
- Once you see apps as assembled from other people's APIs, the rest of this book follows on its own: of course you can talk to these things directly. Everyone's software already does.
Knowledge Check
Where does the weather app's forecast actually come from?
- From the phone's own sensors, which measure the conditions where you happen to be standing
- From a weather service's API, which the app asks and whose answer it displays
- From forecasts downloaded and stored inside the app when it was installed
- From the phone manufacturer, which supplies weather to all of its devices
Why does airplane mode turn a rich app into an empty shell?
- Because apps are built to shut themselves down safely whenever the network disappears
- Because the phone stops all background activity to save battery for the whole flight
- Because the app holds almost no data itself and fetches what it shows from APIs
- Because airplane mode removes the app's permission to read stored content
What does the card terminal at the café actually do when Vera taps her card?
- It checks the card against a list of valid card numbers stored inside the terminal itself
- It connects to the café's own back-office systems, which look up her bank balance
- It asks a payment provider's API whether this card may pay, and shows the answer
- It transfers the money directly from her phone to the café's card reader
You got correct