What is an API? Explained with a waiter in a restaurant
An API is a set of rules that lets one program ask another for data or a task and get an answer back. Explained with a waiter carrying orders between you and the kitchen.
- Author
Umair Mateen- Published
- Reading time
- 5 min
- Category
- Engineering
In one sentence: an API (application programming interface) is a set of rules that lets one piece of software ask another for information or for a job to be done, and get a clear answer back, without seeing how the other side works inside.
The everyday picture
Picture a restaurant. You sit at a table. You are hungry, but you cannot walk into the kitchen and cook. You do not know where the pans are, and the cooks would not want you there.
So you read the menu, tell the waiter what you want, and wait. The waiter carries your order to the kitchen. A little later, the waiter comes back with your dish, or with a polite "sorry, that is sold out."
An API is the waiter. It carries requests from one program to another, and carries the answer back. The menu tells you exactly what you are allowed to order.
Your app reads the menu (documentation), gives its order to the waiter (the API), and the kitchen (the server) does the work out of sight. The waiter brings back the dish (the response).
How it works, step by step
- The documentation (the menu). Every API comes with a description of what you can ask for and how to ask for it. Clear, up-to-date documentation is what makes an API easy to use. You can only order what is on the menu.
- The client (you, the customer). The program that asks is called the client. It could be a phone app, a website or another company's system. A weather app on your phone, for example, is a client asking a weather service for today's forecast.
- The request (your order, given to the waiter). The client sends a message in the exact format the API expects, such as "forecast for this city, for today." It usually includes an API key or a token, which works like showing your reservation: it tells the waiter who is ordering and what they are allowed to have.
- The server (the kitchen). The system that does the work is called the server. It checks the order, looks things up in its stores (its database) and prepares the answer. The client never sees the recipes or the pantry. It only sees the dish.
- The response (the dish coming back). The API returns the answer in an agreed format, for example the temperature and the chance of rain. If something is wrong, such as a missing key or an unknown city, it returns an error message instead, like "sorry, that is not on the menu."
Where the picture stops
- Usually no people are involved. A waiter serves human guests. An API is built for programs to talk to programs. MDN describes it as the counterpart of a user interface: screens and buttons are for people, APIs are for software.
- This waiter has no memory. A good waiter remembers your table. Many web APIs, including the common style called REST, are stateless: the server does not keep track of the client between requests. So every order must carry everything needed, including the key, every time.
- It is much faster and busier. One API can take orders from a huge number of "tables" at once, far faster than any person could. No real waiter works like that.
Why it matters for your business
- Speed. Your tools can share information directly instead of someone copying it by hand. Your website form can send a new lead straight to your CRM.
- Cost. You can use a service someone else has built, such as payments, maps or weather, instead of building your own kitchen.
- Control and risk. AWS notes that APIs let organizations share resources while keeping security, control and authentication, and decide which clients can reach what. Keep your API keys as private as passwords.
- Dependence. When you rely on someone else's API, you rely on their kitchen. If they change the menu or close for repairs, your feature can stop working. Ask how changes are announced before you build on it.
An example
Imagine a 20-person accounting firm. Clients book meetings through a form on its website. Today, an assistant copies each booking into the calendar and the client list by hand, and mistakes creep in.
With APIs, the booking form becomes the customer at the table. It sends one order to the calendar's API ("add this meeting") and one to the client list's API ("add or update this person"). Each kitchen does its work and sends back a confirmation. The assistant now checks a short daily summary instead of retyping every booking.
Frequently asked questions
What does API stand for?
Application programming interface. "Interface" means the meeting point where two things connect. Here, the two things are pieces of software.
Is an API the same as a website?
No. A website is a menu, dining room and plates designed for people. An API returns plain data for other programs to use. Many companies offer both: a website for you, and an API for your software.
What is a REST API?
REST is a popular style for building web APIs. Requests and answers travel over HTTP, the same system web pages use, and each request stands on its own.
Are APIs safe to use?
They can be, when they are set up well. Good APIs check who is asking with keys or tokens and only hand over what that client is allowed to see. Keys must be kept secret and removed when no longer needed.
Related explainers
- Frontend vs backend, explained with a restaurant
- What is caching? Explained with a restaurant kitchen
- What is an LLM? Explained with a new hire who read the whole library
The DevDrift connects business systems through APIs, from web apps to low-code platforms: see how.