Anatomy of a Request
Every HTTP request Postman sends has four components: a method (GET, POST, etc.), a URL made up of a protocol, host, path, and optional query string, a set of headers that carry metadata like Content-Type and Authorization, and, for methods that support it, a body carrying the payload. In Postman, the URL bar and Params tab together build the first two components, the Headers tab lists key-value metadata pairs (with Postman auto-adding common ones like Accept and User-Agent that stay hidden unless you click 'Hidden' to reveal them), and the Body tab holds the payload for write operations. Query parameters live in the URL itself, after a question mark, while path parameters — like an ID embedded directly in the URL such as /users/42 — are edited by clicking directly into the URL text or by using Postman's colon syntax, /users/:id, paired with a Path Variables section.
Cricket analogy: It's like a scorecard entry that always records the batsman, the delivery type, the field placement, and the outcome — a request's method, URL, headers, and body are the fixed fields Postman always tracks for every ball bowled.
Anatomy of a Response
A response mirrors the request's structure: a status line containing the HTTP version and status code (like HTTP/1.1 200 OK), a set of response headers (such as Content-Type telling the client how to parse the body, and Set-Cookie for session management), and a body containing the actual payload, usually JSON for modern APIs. Postman displays these across the response panel's tabs — Body defaults to the Pretty view, Headers lists every response header in a searchable table, and Cookies shows any cookies the server set during that exchange. Status codes fall into five classes: 2xx means success, 3xx means redirection, 4xx means a client-side error like a malformed request or missing auth, and 5xx means a server-side failure — recognizing the class immediately narrows down where to look for the problem.
Cricket analogy: It's like an umpire's decision coming with a signal, a reason, and sometimes a replay, a response's status code, headers, and body together give the full verdict, not just a raw number.
Headers That Matter Most
A handful of headers appear constantly across both requests and responses. Content-Type tells the receiver how to parse the body (application/json, application/xml, multipart/form-data), and mismatching it against the actual body format is one of the most common sources of confusing 400 errors. Authorization carries credentials — a Bearer token, an API key, or Basic auth's base64-encoded username:password — and Postman's dedicated Authorization tab can generate this header automatically rather than requiring you to type it into the raw Headers list. On the response side, Cache-Control and ETag headers govern caching behavior, and Postman respects these by default unless you disable caching from Settings, which occasionally explains why a response looks 'stale' compared to what the server actually just sent.
Cricket analogy: It's like the toss result determining who bats first, a small piece of information (Content-Type or Authorization) that determines how the entire rest of the exchange proceeds.
Postman's Headers tab has a toggle to show 'Hidden' headers — ones Postman adds automatically, such as User-Agent, Accept-Encoding, and Connection. These are genuinely sent with the request even though they're collapsed from view by default, and checking them via the Postman Console is the only way to see their exact values.
A 4xx status code means the problem is with the request you sent (bad syntax, missing auth, wrong path), while a 5xx means the problem is on the server. Don't waste time re-checking your request's headers and body if you're getting a consistent 500 — that error means something broke on the server's side regardless of what you sent.
GET /v1/orders/789 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"orderId": 789,
"status": "shipped",
"total": 89.97
}- A request has four parts: method, URL (with path/query params), headers, and body.
- A response mirrors this with a status line, response headers, and a body.
- Query parameters live after the ? in the URL; path parameters are embedded directly in the URL path.
- Content-Type tells the receiver how to parse the body; mismatches cause confusing 400 errors.
- Authorization carries credentials and can be auto-generated via Postman's Authorization tab.
- Status code classes: 2xx success, 3xx redirection, 4xx client error, 5xx server error.
- Postman's Headers tab hides auto-added headers like User-Agent by default; toggle 'Hidden' to view them.
Practice what you learned
1. What are the four components of an HTTP request?
2. Where do query parameters appear in a URL?
3. What does a mismatched Content-Type header commonly cause?
4. Which status code class indicates a server-side failure?
5. Where can Postman generate the Authorization header automatically rather than typing it manually into Headers?
Was this page helpful?
You May Also Like
HTTP Methods in Postman
How to use GET, POST, PUT, PATCH, and DELETE requests in Postman, including when each method applies and how to attach a request body.
Making Your First Request
A step-by-step walkthrough of building and sending your first GET request in Postman, reading the response, and saving the request for reuse.
The Postman Interface
A tour of Postman's main workspace layout — sidebar, request builder, response viewer, and console — and how each panel supports the request-response workflow.