HTTP, Clients, Servers, and the Request/Response Model

Your browser is a client. So is the curl tool in your terminal. If you write a backend service that calls an external payment API, your backend is the client for that request, and the payment provider is the server. The exact same machine can be a server for one request and a client for the next. When you read the words "client" and "server" in this course, just ask yourself which side is doing the asking right now.

Stateless: every request starts from zero

This is the part that often surprises beginners: HTTP is stateless. The server doesn't remember anything about your previous requests. Each request arrives carrying all the information the server needs to handle it. The instant the server replies, it completely forgets you.

That sounds like a terrible design flaw, but it is actually the reason the web scales so incredibly well. Because the server doesn't rely on memory from past requests, a popular website can run a hundred identical servers behind the scenes and let any of them handle your next click. There is no complicated memory to sync between them.

The obvious question is: if the server forgets me instantly, how do I stay logged into a website? The answer is that you re-prove you are logged in on every single request. The browser does this invisibly by attaching a small token or cookie every time it asks for something. Statelessness is the default rule; memory is carefully layered on top. We dedicate an entire section to how this works later.

Seeing it as plain text

HTTP isn't a complex, unreadable binary format. A request is just plain text. Here is roughly what your browser sends behind the scenes:

And here is the kind of plain-text response the server sends back:

That is real HTTP. Those are the actual bytes on the wire. You could type it by hand if you wanted to.

What HTTP is not

A few concepts frequently get bundled together with HTTP that are completely different things:

• HTTP is not HTML. HTML is just one type of file that HTTP can carry. HTTP is perfectly happy carrying JSON, images, video files, or PDFs. The protocol does not care what the payload is.
• HTTP is not a programming language. It is a format for sending messages. You don't write logic in it.
• HTTP is not tied to browsers. Apps, background scripts, and smart TVs all speak it. Any program that formats its text correctly can join the conversation.

Keeping HTTP and HTML separate in your head makes everything that follows much clearer.

It is HTTP the whole way down

Here is one final concept to keep in mind. Between your browser and the code that actually builds the response, a request usually passes through several different machines: a local CDN, a load balancer, and finally an application server. Each one of those machines speaks HTTP to the next one in line.

To your browser, it looks like a single clean request and a single response. Underneath, multiple HTTP exchanges are chained together to make it happen. We cover each of those machines in the architecture section.

Try it now

You can view a raw request and response with your own eyes in the terminal:

In the output, the lines beginning with > are the request your machine sent. The lines beginning with < are the response that came back. You are reading raw HTTP — the same shape as the text blocks above, captured from a real server.

What's Next

Every request begins by naming the one thing it wants: a URL. The next chapter takes the URL apart piece by piece and explains what a "resource" really is.