Client and Server

Every API conversation in the last two pages — the weather question, the bus positions, the card payment — had the same two roles in it. One side asks; the other side answers. The asker is called the client, the answerer is called the server, and which is which never changes in the middle of a conversation. It sounds almost too simple to deserve its own page. It turns out to be the most clarifying pair of words in this book.

Think of a call-in radio show. Listeners phone the station; the station never phones a listener out of the blue. Every call starts fresh, gets handled, and ends. That is the whole model — and once you have it, an enormous amount of API behavior stops being mysterious.

Who Asks, Who Answers

The client starts every exchange. It sends a request — the ask — and the server sends back a response — the answer. One request, one response, done. The server never calls first: it sits and waits, all day, for requests to arrive. (Chapter 9 will show a beautiful arrangement where news does travel the other way — but it works by carefully swapping the roles, not by breaking the rule, and it will make sense precisely because the rule came first.)

Roles, Not Machines

"Server" names a job, not a box in a basement. It is whichever program is answering — and the same computer can be a server to you while being a client to a database standing behind it, the way a shop assistant serves you and simultaneously orders stock from a supplier. Today, Vera's laptop is the client and Tandem's machines are the server. The words describe who is asking whom, nothing more.

Each Request Stands Alone

Here is the rule with the longest shadow: by default, the server does not remember the conversation — who asked last, or what they asked. Each request must carry everything the server needs to answer it — like the radio station, where every call starts from scratch and you introduce yourself again. The technical word is stateless: no running conversation state is kept between exchanges. What the server stores is another matter entirely — a reservation you create stays created. It is the thread of your visit that is forgotten, not the data.

Why build it this way? Because a server answering millions of strangers cannot afford to keep notes on all of them between calls — forgetting everyone the moment it answers is what lets one server serve a city. This is the simplified picture; there are arrangements that layer memory on top, and you will meet one in Chapter 5. But the default explains two things you will run into soon: why your key must travel with every single request (Chapter 5), and why getting a long list means asking for it page by page (Chapter 8).

Whose Side Is the Problem On?

The two-role split hands you the most valuable practical instinct an API user can own. When something goes wrong, there are exactly three places to look: the asking side, the answering side, or the road between them. Was the request built wrong — the client's fault? Did the answering program fail — the server's fault? Or did the message not get through at all? Chapter 7 will teach you to tell which is which from the answer itself. This page only plants the question. Chapter 7 sharpens it: whose side is the problem on?