Clients, Servers, and the Request-Response Cycle

Open any app, tap Buy, and a second later you see a confirmation. In that second, two programs on two different machines had a short, precise conversation. Every system in this course, however large it grows, is built from that one conversation, so it is worth slowing down once and looking at it properly. By the end of this chapter you will be able to say who asks, who answers, what is in the message, and what can go wrong.

Think of a restaurant. You are the customer: you decide what you want and ask for it. The kitchen is the only place that can actually make it. Between you, a waiter carries a written order to the kitchen and brings a plate back. Neither side does the other's job, and neither needs to know how the other works inside. You do not need the recipe, and the kitchen does not need to know why you are hungry.

• -The customer is the client: whatever starts the conversation by asking for something. It is usually a browser or a mobile app, but it can also be another server, or a script that runs on a timer.
• -The kitchen is the server: a program that waits for requests, does the work, and sends back an answer.
• -The written order is the request, and the plate that comes back is the response.
• -The waiter and the road to the kitchen are the network: they carry messages but do not change them.
• -The menu is the list of things the kitchen agrees to make. In software, that list is the server's interface, often called its API.

Here is the part that surprises most beginners: client and server are roles in one particular exchange, not kinds of computer. The same program can be a server in one conversation and a client in the next. When your browser asks a web server for a page, the web server is the server. But to build that page, the web server asks a database for your orders, and in that second conversation the web server is the client and the database is the server. One request often fans out into a chain of smaller conversations like this, which is exactly why later chapters keep adding boxes between the first client and the last server.

The word server also does not mean one physical machine. One machine can run many servers side by side (a web server, a database, a mail server), and one server in a diagram might really be dozens of machines working together behind a single address. You will see how that works in the next module.

A request is just a short piece of structured text. Here is a browser asking a shop for the page about product 42:

The first line says what the client wants: a method (GET means read something) and a path (which thing). The lines below are headers, extra information such as which website this is for and who the user is. A request that sends data, like submitting a form, also has a body underneath. The server answers in the same shape:

The number on the first line is the status code. 200 means success, and you will meet the rest in the HTTP chapter. Notice that the whole conversation is readable text. Nothing magic is happening: one side writes a message, and the other reads it and writes one back.

Put it together and a single click does this:

• -The client works out where the server is. A name like shop.example.com is turned into a numeric address (the DNS chapter).
• -It opens a connection to that address (the TCP chapter), and agrees on encryption if the site uses HTTPS (the HTTP and TLS chapter).
• -It sends the request.
• -The server reads the request, does whatever work is needed (looks something up in a database, checks a price, saves an order), and builds a response.
• -The response travels back over the same connection.
• -The client uses it: a browser draws the page, an app updates its screen, a script reads the data and carries on.

Each of those steps has its own chapter in this module. For now, hold on to the shape: ask, work, answer.

One more idea belongs here, because it shapes every design in this course. A client is outside your control. Anyone can open their browser's developer tools, or write a ten-line script, and send your server any request they like, including requests your own app would never send.

Suppose your checkout page sends the item number 42 and a price of 29.99. A curious visitor changes the price to 0.01 before it is sent. If the server simply believes the request, it just sold a lamp for a cent. The fix is not a smarter browser. The fix is that the server looks up the real price itself and ignores the one the client sent. The same rule applies to who the user is, what they are allowed to do, and whether their input is well-formed: the server checks everything, every time. Treat what a client sends like a handwritten note on a check: it might be genuine, but nothing happens until it has been checked.