How the HTTP Protocol Works

beginner
10 min

How the HTTP Protocol Works

Every REST API you will ever build or consume runs on top of HTTP, the Hypertext Transfer Protocol. Before you design endpoints or write server code, it pays to understand what actually happens when a client talks to a server. In this lesson we break down the request-response cycle, the anatomy of requests and responses, and the properties of HTTP that shape how REST APIs are designed.

The Request-Response Cycle

HTTP is a client-server protocol. The client (a browser, a mobile app, or another server) always initiates the conversation by sending a request. The server processes it and sends back exactly one response. There is no way for a plain HTTP server to push data to a client that has not asked for anything.

A typical cycle for a REST API call looks like this:

  1. The client resolves the API domain (like api.example.com) to an IP address using DNS.
  2. It opens a TCP connection to the server, usually on port 443 for HTTPS.
  3. It sends an HTTP request describing what it wants.
  4. The server routes the request to your application code, which builds a response.
  5. The response travels back and the client parses it.

Anatomy of an HTTP Request

An HTTP request is just structured text. It has three parts: a request line, headers, and an optional body.

http
POST /api/orders HTTP/1.1 Host: api.shopcraft.com Content-Type: application/json Authorization: Bearer eyJhbGciOi... {"productId": 42, "quantity": 2}

The request line contains the method (POST), the path (/api/orders), and the protocol version. Headers are key-value pairs carrying metadata: what format the body is in, who the caller is, what response formats are acceptable. The body carries the actual payload, here a JSON object describing an order.

Anatomy of an HTTP Response

The response mirrors the request: a status line, headers, and a body.

http
HTTP/1.1 201 Created Content-Type: application/json Location: /api/orders/981 {"id": 981, "productId": 42, "quantity": 2, "status": "pending"}

The status code (201) tells the client at a glance whether the request succeeded. The Location header points to the newly created resource, and the JSON body returns its full representation. Well-designed APIs use all three layers deliberately rather than stuffing everything into the body.

HTTP Is Stateless

Each HTTP request is independent: the server does not remember anything about previous requests from the same client. This is called statelessness, and it is a cornerstone of REST. If a request needs context, such as who the user is, the client must include it every time, usually in an Authorization header.

Statelessness sounds like a limitation, but it is what makes APIs scale. Because any server can handle any request, you can put ten identical servers behind a load balancer and none of them needs to share session memory.

HTTP Versions in the Real World

HTTP/1.1 (1997) is still everywhere and is what most examples show. HTTP/2 multiplexes many requests over one connection, which makes busy APIs faster without changing your application code. HTTP/3 runs over QUIC instead of TCP for lower latency. The good news: the request and response semantics you learn here are identical across versions, so your REST knowledge transfers directly.

Key Takeaways

  • HTTP is a text-based, client-initiated request-response protocol.
  • Requests contain a method, path, headers, and an optional body; responses contain a status code, headers, and a body.
  • HTTP is stateless: every request must carry all the context the server needs.
  • The same semantics apply whether the wire protocol is HTTP/1.1, HTTP/2, or HTTP/3.

Next up: HTTP Methods: GET, POST, PUT, PATCH, DELETE, where we learn what each verb means and when to use it.