A2 · HTTP Request Anatomy: An HTTP request is like a **shipping parcel**: an **action label** (method — fetch/send/delete), an **address** (URL — to whom), **shipping notes** (he
An HTTP request is like a **shipping parcel**: an **action label** (method — fetch/send/delete), an **address** (URL — to whom), **shipping notes** (headers — how to pack it, who is sending), and, when present, the **package inside the box** (body — the data being carried). But if we already wrote the address, why also need a method? Because to the same address (`/api/v1/bugs`) you can say both "fetch the list" (GET) and "add a new one" (POST) — the address says WHERE, the method says WHAT TO DO. In Java the equivalent is a method call: the URL is the object's name, the method is the function you call, headers are `@RequestHeader`, and the body is the `@RequestBody` parameter. Its QA importance: a bug's source is often not in the body but in an overlooked header — omit `Content-Type: application/json` and the server cannot parse the JSON and treats the body as empty; the request was "sent" but the server says "I received an empty box." This is one of the silent traps testers fall into most.
The Four Parts of a Request
🎬 The Four Parts of a Request: Opening the Parcel
You send a POST request. Inside this single parcel that reaches the server there are actually four parts — which does what?
Method + URL together say "WHAT + WHERE": POST + /api/v1/bugs = "create a NEW bug here". Had you said GET to the same URL it would mean "fetch the list".
Headers are the packing notes: without `Content-Type: application/json` the server won't treat the body as JSON — it can't open the box and says "arrived empty".
The body is the actual carried data — present only in POST/PUT/PATCH. Sending a body with GET is ignored by most servers.
The lesson — All four parts must be right: wrong method = wrong action, wrong URL = 404, missing header = empty body, malformed body = 400. The tester tests each part separately.
Why Is a Header a Silent Bug Source?
Content-Type missing…
Omit `Content-Type: application/json` and the server treats the body as plain text and does not parse it as JSON.
Server sees an empty body…
An unparseable body arrives as `null`/empty in most frameworks — as if you sent no data at all.
The result can be 400 (required field empty) or a silent 201 (empty record). A tester looking at the symptom blames the body, but the culprit is the header.