HTTP — One Request, One Response
Nearly every web API speaks HTTP. If you can read a raw HTTP message, you can debug almost any API problem, because every framework and library is only building these few lines of text for you.
The rule
A request asks with a method and a path; a response answers with a status.
An HTTP request has three parts:
- A request line: method, path and version, such as
GET /v1/books/42 HTTP/1.1. - Headers:
Name: valuelines of extra information, likeHostorAccept. - An optional body, separated from the headers by a blank line.
A response mirrors it: a status line (HTTP/1.1 200 OK), headers, a blank line, then an optional body.
POST /v1/loans HTTP/1.1
Host: api.booknook.example
Content-Type: application/json
{"book_id": 42, "member_id": 7}
HTTP/1.1 201 Created
Location: /v1/loans/901
Content-Type: application/json
{"id": 901, "book_id": 42, "due": "2026-10-09"}HTTP is stateless: each request carries everything the server needs to understand it. The server does not remember that the same app asked for book 41 a second ago. Anything that must persist between requests, like who the user is, travels in every request, usually in a header.
HTTP has grown through versions, but the meaning of a message has stayed the same:
- HTTP/1.1 sends text messages, one at a time on each connection.
- HTTP/2 sends the same messages as binary frames and multiplexes many requests over one connection at once.
- HTTP/3 runs HTTP/2's ideas over QUIC, a protocol built on UDP, so one lost packet does not stall every other request.
Methods, paths, headers and status codes mean the same in all three. You design an API once; the version is a transport detail.
The shortcut
Read any exchange in four glances: method, path, status, body. Those four tell you what was asked, of what, how it went and what came back.
Method
POST: the client wants to create something.
The trap is looking only at the body. A body that says "ok" alongside a 500 status is still a failure; the status line is the server's real answer.
Drills
Answer fast — trust the rule.
In GET /v1/books/42 HTTP/1.1, what is /v1/books/42?
What separates the headers from the body in an HTTP message?
HTTP is stateless. What does that mean for BookNook?
What is HTTP/2's main improvement over HTTP/1.1 for a busy API client?
Remember
- A request asks with a method and a path; a response answers with a status.
- Shortcut: method, path, status, body — in that order.
- Trap: trusting the body over the status line; HTTP versions change transport, not meaning.