The request-response model

Every web interaction follows the same pattern

Every time you open a website, click a link, or submit a form, the same thing happens behind the scenes. Your browser sends a message to a server somewhere on the internet, and that server sends a message back. The browser says “give me this page,” and the server says “here it is.” This back-and-forth is called the request-response model, and it is the foundation of HTTP (HyperText Transfer Protocol). Before we write any server code in this course, we need to understand this pattern, because every API, every web page, and every backend service you will ever build relies on it.

Two players: client and server

There are only two roles in this conversation.

A client is anything that sends a request. The most common client is a web browser like Chrome, Firefox, or Safari. But a client can also be curl (a command-line tool for making requests), JavaScript’s built-in fetch function, a mobile app loading data from a backend, or even another server calling an external API. If it sends an HTTP request, it is a client.

A server is a program that listens for requests and sends back responses. In this course series, the server is a Node.js process. The server just sits there, waiting. A request arrives. The server does some work (reads from a database, runs some logic, checks who the user is), puts together a response, and sends it back. Then it waits again.

That is the entire relationship. The client asks, the server answers. The server never reaches out first. It only speaks when spoken to.

Client                          Server
  |                               |
  |  ---- HTTP Request ----->     |
  |                               |  (process the request)
  |  <--- HTTP Response ----      |
  |                               |

One request, one response. Always in that order.

[!NOTE] WebSockets (covered in the Real-Time APIs course) break this pattern. With WebSockets, the server can push data to the client without being asked. But even WebSockets start as an HTTP request that “upgrades” to a persistent connection. HTTP is always the starting point.

What actually happens when you type a URL

Let’s say you type https://example.com/books into your browser. Here is what happens:

1. The browser looks up example.com’s IP address. This is called a DNS lookup, and it is like looking up a phone number in a phone book. The browser needs to know where on the internet this server lives.
2. The browser opens a connection to that IP address. This is called a TCP handshake, and it establishes a reliable communication channel between your computer and the server.
3. The browser encrypts the connection. This is called a TLS handshake, and it is what the “s” in “https” stands for. It makes sure nobody can eavesdrop on the conversation.
4. The browser sends an HTTP request: GET /books.
5. The server processes the request and sends back an HTTP response: 200 OK with the page content.
6. The browser renders the response on your screen.

Steps 1 through 3 happen before HTTP even starts. Steps 4 and 5 are the actual HTTP request and response. This course focuses on 4 and 5. We will cover the connection steps (1 through 3) later in Section 6.

HTTP messages are just text

Here is something that surprises a lot of people: HTTP messages are plain text. There is nothing magical or binary about them. A request looks like this:

GET /books HTTP/1.1
Host: example.com
Accept: application/json

And a response looks like this:

HTTP/1.1 200 OK
Content-Type: application/json

[{"id":"book-1","title":"The Left Hand of Darkness"}]

These are human-readable strings. You could write them by hand if you wanted to. The next two lessons will take these messages apart piece by piece so you know exactly what every line means.

Exercises

Exercise 1: Open your browser’s developer tools (F12 or right-click and select “Inspect”). Go to any website. Click the “Network” tab. Each row you see is one request-response pair. Click on one and look at the details.

Exercise 2: Run curl -v https://example.com in your terminal. The -v flag shows the raw request and response. Try to identify the request line, the headers, and the response status code.

Exercise 3: Count how many HTTP requests your browser makes when loading a single web page. Open the Network tab, then refresh the page. You will probably see dozens of requests: one for the HTML, more for CSS, JavaScript, images, fonts, and API calls.