Anatomy of an HTTP request

Clients and servers talk in HTTP

Every time you open a web page, submit a form or an app loads data, a client (browser, mobile app, another server) sends a request to a server, and the server sends back a response. The rules for that conversation are HTTP — the HyperText Transfer Protocol.

The surprising part: HTTP messages are just plain text in a fixed format. Once you can read them, debugging backends gets much easier.

The request

Here is a real request a browser might send to create a to-do item:

POST /api/todos HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
 
{"title": "Learn HTTP", "done": false}

It has three parts:

1. Request line — POST /api/todos HTTP/1.1: the method (what to do), the path (which resource), and the protocol version.
2. Headers — Name: value lines with extra information: which site (Host), the body format (Content-Type), the format we'd like back (Accept), who we are (Authorization).
3. Body (optional) — the data being sent, separated from the headers by an empty line. GET requests usually have no body.

Methods: the verbs of HTTP

The response

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/todos/42
Date: Tue, 06 Oct 2026 10:15:00 GMT
 
{"id": 42, "title": "Learn HTTP", "done": false}

Same shape, different first line: the status line contains a status code (201) and a human-readable reason (Created). Then headers, an empty line, and the body.

Status codes: five families

The first digit tells you who's "at fault":

HTTP is stateless

Each request stands on its own. The server doesn't automatically remember that you sent a request a second ago. If it needs to know who you are, every request has to say so — usually with a cookie or an Authorization token in the headers.

Statelessness is a feature: any server in a cluster can handle any request, which is what makes backends easy to scale. You'll see this idea again in the Performance & scaling and Auth & security modules.

Try it

Send requests to a small mock API. Try the presets, then experiment: remove the Content-Type header from a POST, send invalid JSON, or use the wrong method on a URL.

How this maps to .NET

In ASP.NET Core (Track 11), you describe what to do for each method + path, and the framework handles the raw text for you:

app.MapPost("/api/todos", (Todo todo) =>
    Results.Created($"/api/todos/{todo.Id}", todo));   // → 201 Created + Location header

Key takeaways

• A request = method + path + headers + optional body; a response = status code + headers + optional body.
• Use methods for their meaning: GET reads, POST creates, PUT/PATCH update, DELETE removes.
• Status code families: 2xx success, 3xx redirect, 4xx client mistake, 5xx server problem.
• HTTP is stateless — identity travels with every request.