How an HTTP request works: methods, headers, and body

Every time a browser loads a page or an app calls an API, it sends an HTTP request and gets back an HTTP response. Both are made of the same three parts: a first line, a list of headers, and an optional body.

A request, line by line

Here is a request that creates a new item through a JSON API. The blank line separates the headers from the body.

POST /api/items?draft=true HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer YOUR_TOKEN_HERE
Content-Length: 34

{"name": "notebook", "price": 4.5}

• Request line: the method (POST), the path plus optional query string (/api/items?draft=true), and the protocol version.
• Headers: Name: value pairs that describe the request. Host says which site you want, Content-Type describes the body, Accept says what format you want back.
• Body: the data you send. GET requests normally have none; POST, PUT, and PATCH usually do.

HTTP/2 and HTTP/3 send the same information in a compact binary form, but the model of method, path, headers, and body is identical, and tools such as browser DevTools show it to you in this readable shape.

The common methods

• GET: read something. Should not change data on the server.
• POST: create something or trigger an action.
• PUT: replace a resource with the body you send.
• PATCH: change part of a resource.
• DELETE: remove a resource.
• HEAD: like GET, but only the headers come back. OPTIONS: ask what is allowed; browsers use it for CORS preflight checks.

GET, HEAD, OPTIONS, PUT, and DELETE are idempotent: sending the same request twice has the same effect as sending it once. POST is not, which is why clients should be careful about retrying it automatically.

The response

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/items/42

{"id": 42, "name": "notebook", "price": 4.5}

The first line carries a three-digit status code: 2xx means success, 3xx a redirect, 4xx a problem with the request, and 5xx a problem on the server. Response headers describe the body, caching rules, cookies, and more.

What happens around the request

1. The client looks up the server’s IP address with DNS.
2. It opens a connection, and for https:// URLs it performs a TLS handshake so the traffic is encrypted and the server’s certificate is checked.
3. It sends the request and waits for the response.
4. The connection is usually kept open and reused for further requests to the same server.

Seeing it yourself

Open your browser’s DevTools, switch to the Network tab, and reload a page. Click any row to see the request headers, response headers, and body. From a terminal, curl -v https://example.com prints the lines it sends (marked >) and receives (marked <).

Two practical rules follow from all this. Never put secrets or personal data in the URL, because URLs end up in logs and browser history; send them in headers or the body over HTTPS. And always set Content-Type when you send a body, because many servers refuse or misread bodies without it.