Topic 08

The Response: Status Line, Headers, Body

HTTP

The answer comes back wearing the same suit. A response — what the server sends in reply — has the same three-part anatomy as the request: a leading line, then headers, then a body. It is the mirror image of what you sent, and having learned one side, you already mostly know the other.

Here is what comes back when the app asks about Old Market — the actual reply to the last page's request:

The complete response to the Old Market request
HTTP/1.1 200 OK
Content-Type: application/json
Date: Thu, 20 Aug 2026 09:14:07 GMT

{"id": "st_014", "name": "Old Market", "capacity": 24,
 "free_bikes": 9, "status": "active",
 "location": {"lat": 47.21, "lon": 8.55}}

The Status Line: the Verdict

The response leads with HTTP/1.1 200 OK — dialect, number, phrase. The number is a status code: the server's one-glance verdict on your request. 200 means it worked. The phrase after it is just the number in words. Two pages from now you will learn to read the whole family of these numbers at a glance; for now, know where the verdict sits — first line, always.

Response Headers: the Server's Envelope Notes

Then headers, same format as yours: Name: value, one per line, now written by the server. The one to meet today is Content-Type: application/json — the label announcing what kind of thing the body is. Here it says JSON, the data format Chapter 4 teaches you to read. Other notes will matter later: counters that track your request allowance (Chapter 8), identifiers that help support find your request in their logs (Chapter 7). The habit is the same as the last page: the envelope notes are short, and they are worth a glance.

The Body: the Actual Answer

After a blank line comes the body — the thing you asked for. Old Market, station st_014, capacity 24, nine bikes free right now, active, and its coordinates. You can already read most of it cold, which is the point of showing it before JSON gets its formal introduction. The braces and brackets have exact rules, and Chapter 4 makes you fluent in them; but notice that even now, nothing in this answer is intimidating. It is a luggage tag's worth of facts about one bike station.

One Conversation, Both Halves

Put the two pages together and you have the complete atom of this book. A handful of lines out; a verdict, a few notes, and an answer back. Every page ahead — keys, errors, pagination, webhooks — is this same exchange with one detail turned up. When Vera watches her first live conversation in the next chapter, she will recognize both halves on sight. So will you.

The mirror image
Request
Request line · headers · (sometimes) a body. Written by the client.
Response
Status line · headers · (usually) a body. Written by the server.
Common Confusions
  • "If I got a response, it worked." An error is a response too, wearing the same suit with a different verdict on line one. Arriving and succeeding are different things — the status line tells you which happened.
  • "The body is the response." The body is one third of it. When things go sideways, the status line and the headers routinely matter more than the body — they are where the verdict and the evidence live.
  • "200 OK means I got what I wanted." It means the server understood the request and answered it. Whether the answer matches your intent — right station, right filter, right day — is still yours to check.
  • "The blank line before the body is just formatting." It is the official divider: headers end, body begins. Tools rely on it, and now you know why the shape looks the way it does.
Why It Matters
  • Every error page in Chapter 7 is exactly this structure with a different number and story. Learn the anatomy on a sunny day, and rainy days lose most of their menace.
  • Content-Type decides which reading skills to apply to the body. Glancing at it is a two-second habit that prevents long confusions — "garbled data" is usually just an unexpected format, honestly labelled.

Knowledge Check

What does the status line of a response carry?

  • The answer to your question, compressed into a single line
  • The server's verdict: the HTTP version, a status code, and its phrase
  • The label announcing what format the body is written in
  • A copy of your original request, so you can check what was received

A response arrives with a status code that is not 200. What has definitely happened?

  • Nothing came back at all — a missing 200 means the request was lost on the road
  • The server has crashed and could not process the request
  • The conversation happened, and the verdict was something other than 200 OK
  • Your request was built incorrectly and needs to be fixed

What does the Content-Type header on a response tell you?

  • What format the body is in, so you know how to read it
  • How large the answer is, so your device can prepare for it
  • Whether the request succeeded or failed, in machine-readable form
  • Which kind of client sent the request — a browser, an app, or a tool

You got correct