An API is like a restaurant waiter. You don't go into the kitchen: you place your order with the waiter, they pass it on, and bring back your dish. An API does the same between two pieces of software. Watch the scene. 👇
01 · What it is02 · Request→response03 · Endpoint…
The game · place an order
The waiter is the API
🧑💻
You (the app)
You want something
"A weather report, please"
🍽️ "Here you go: 24°C ☀️"
🤵
The API (the waiter)
Passes on & brings back
1 You place an order → you ask the API
2 The API goes to the "kitchen" (the server with the data)
3 It brings back the response — without you seeing the kitchen
🔌 That's an API. A go-between that takes your request, fetches the info from another service, and brings it back — without you needing to know how it's made in the kitchen. It's what lets two pieces of software talk: your app and the weather, your shop and the payment, your site and an AI.
What this teaches you
A go-between, not magic
🤵 It makes the link
The API connects two pieces of software. One asks, the other answers. You don't have to enter the other's kitchen.
📋 A menu of possibilities
Like a restaurant menu, an API offers a list of things you can ask it for. Nothing more, nothing less.
Check that you got it
2 quick questions
1. An API is mostly…
Right: like the restaurant waiter, it links you and the "kitchen" (the other service).
2. Do you need to know the other service's "kitchen"?
Right: that's the whole point. You ask, the API hides the complexity and hands back the result.
What to remember
An API = a restaurant waiter: it passes on your request and brings back the response.
It connects two pieces of software without you seeing the other's kitchen.