What Is an API? The Client-Server Request-Response Model
🔌 What Is an API? The Client-Server Request-Response Model
The Client-Server Model
Almost every API involves two sides: a client, which asks for something, and a server, which has the data or logic to answer. Think of a restaurant: you (the client) don't walk into the kitchen and cook your own meal — you tell a waiter what you want, and the kitchen (the server) prepares it and sends it back out. You never need to know how the kitchen works internally; you just need to know how to place an order and what to expect back.
Client
Whatever initiates the request — a browser, a mobile app, a script, or even another server. The client wants something: data, an action performed, or both.
Server
Whatever holds the data or logic the client wants, and knows how to respond to a properly formed request. One server can serve many different clients at once.
What "API" Actually Means
API stands for Application Programming Interface — a defined way for one piece of software to ask another for something, without needing to know how that other piece works internally. The key word is interface: it's a contract. As long as both sides honor the contract, the client doesn't care whether the server is written in Python, Go, or PHP, and the server doesn't care whether the client is a phone app or a script running on someone's laptop.
A Person Using a Website vs. a Program Using an API
Human via Browser (UI)
A person fills in a search box, clicks a button, and reads the results as rendered text and images on a page — built for human eyes.
Program via API
A program sends the same underlying search request in a structured format and gets back structured data it can parse — built for another program to consume, not for a human to read directly.
Both might hit the exact same underlying search feature — the difference is who's on the other end of the request, and what shape the response takes.
Request/Response: The Basic Exchange
Most APIs — though not all, as later chapters cover — follow the same basic pattern: the client sends a request describing what it wants, the server does whatever work is needed, and sends back a response. Stripped of any specific technology, a request/response exchange might look conceptually like this:
A Generic Request/Response Exchange
That's the whole shape of it, conceptually. Chapter 2 makes this concrete with HTTP — the actual protocol most web APIs use to carry requests and responses across a network.
Not All APIs Talk Over a Network
"API" is actually a broader term than just "web API." When you call a function from a JavaScript library, or use the browser's built-in fetch() function, you're using a library API — an interface to code running in the same program, with no network involved at all. This course is specifically about web APIs: interfaces for communication between separate systems, usually over a network, usually between a client and a server that are entirely different programs — possibly written by different teams, running on different machines, in different parts of the world.
Library API (not this course's focus)
Function signatures and classes exposed by a piece of code running inside your own program — e.g. the DOM API, or a Python library's public functions. No network call happens.
Web API (this course's focus)
A separate system — usually a server somewhere else — that your program talks to over a network, sending a request and getting back a response. This is what REST, SOAP, gRPC, and GraphQL all are.
🗺️ Where This Course Fits
If you've already come across GraphQL or WebSockets elsewhere on this site, both are web APIs too — just different styles, each with their own full course already. This course covers the broader family of request/response-style web APIs (REST, SOAP, RPC-style APIs, and Webhooks), and Chapter 8 closes with a direct comparison across all of them — including where GraphQL and WebSockets fit — so you can choose the right style for a given job instead of defaulting to whichever one you've heard of most.
| API Style | One-Line Description | Where It's Covered |
|---|---|---|
| REST | Resource-based request/response, almost always over HTTP | This course, Chapters 3–4 |
| SOAP | XML-based, strict formal contracts (WSDL) | This course, Chapter 5 |
| RPC-style (JSON-RPC, gRPC) | "Call this specific function" rather than "fetch this resource" | This course, Chapter 6 — gRPC has its own full course too |
| GraphQL | Client asks for the exact shape of data it wants back | Already covered — its own course |
| WebSockets | A persistent, two-way connection — not really request/response at all | Already covered — its own course |
| Webhooks | The server calls you when something happens, instead of you asking it | This course, Chapter 7 |
💻 Coding Challenges
Challenge 1: Identify Client and Server
For each of the following, say which side is the client and which is the server: (a) a weather app on your phone showing today's forecast, (b) a browser loading a news website, (c) a smart thermostat reporting the current temperature to an app on your phone.
Goal: Practice spotting the client/server roles in everyday situations, not just abstract diagrams.
Challenge 2: Spot the API in Everyday Life
Pick one app or website you use regularly. Describe one moment where it's very likely making a web API call behind the scenes, and sketch — in plain words, no syntax needed — roughly what the request might ask for and what the response might contain.
Goal: Practice recognizing that a request/response exchange is happening even when it's invisible to the user.
Challenge 3: Library API or Web API?
Classify each of the following as a "library API" or a "web API," and justify each answer in one sentence: (a) calling Array.map() in JavaScript, (b) a weather app fetching a forecast from a remote server, (c) using Python's built-in len() function, (d) a mobile game submitting a high score to a leaderboard server.
Goal: Practice telling apart the two meanings of "API" this chapter distinguished.
In casual conversation, "API" gets used for almost anything — "the DOM API," "the Fetch API," "our internal API" — and not all of those involve a network at all. When someone says "call the API" in a professional context, they almost always mean a web API: a request going out to a separate server. But "the Array API" or "the DOM API" refers to functions built into a language or browser, running entirely inside your own program. Mixing these up is a common beginner confusion — when in doubt, ask whether a network request is actually involved.
🎯 What's Next
With client/server roles and the request/response idea established conceptually, the next chapter gets concrete: HTTP as the Foundation of Most APIs — the actual methods, status codes, and headers that carry a real request and response across a network.