Postman Basics
📮 Postman Basics
The Postman Interface, in Brief
A request builder in Postman has, left to right: a method dropdown (GET, POST, PUT, DELETE...), a URL bar, and a row of tabs — Params, Headers, Body, and a few others this chapter doesn't need yet. Below that, after clicking Send, a response pane shows what came back.
Building Your First Request
The simplest possible request: pick GET, type a URL, click Send.
The response pane immediately shows three things worth reading before even looking at the body: the status code (e.g. 200 OK), the response time (e.g. 184 ms), and the response size. All three are useful signal on their own — a 404 means "look at the URL, not the body," a jump from 100ms to 3 seconds is worth investigating regardless of whether the body looks correct.
Query Parameters
The Params tab lets you add key/value pairs without hand-typing a ?key=value&key2=value2 string — Postman builds the URL for you as you type, and keeps each parameter individually toggleable (useful for quickly testing "what if I remove just this one filter").
Headers
The Headers tab adds custom HTTP headers — most commonly an Authorization header carrying a token, or a Content-Type header describing the body's format.
Request Body
For a POST or PUT, the Body tab is where the actual payload goes. Selecting raw and then JSON as the format gives a text area for hand-writing a JSON object, with Postman validating the syntax as you type.
Inspecting the Response
The response side has its own tabs mirroring the request's: Body (with Pretty/Raw/Preview views — Pretty auto-formats JSON for readability), Cookies, and Headers (worth checking for things like rate-limit counters or a returned Location header after a successful creation).
| Tab / Element | Purpose |
|---|---|
| Params | Query string key/value pairs, auto-appended to the URL |
| Headers | Custom HTTP headers sent with the request |
| Body | The request payload — raw JSON, form data, or other formats |
| Response status/time/size | The first three things worth checking before reading the body at all |
| Response Body (Pretty) | Auto-formatted, readable view of a JSON response |
Query Params vs. Request Body — When Each Is Used
Query Parameters
Filtering, sorting, and pagination on a GET — small, URL-safe values that describe which data to fetch.
Request Body
The actual data being sent to create or update something on a POST/PUT — can be arbitrarily large and structured, and never appears in the URL.
Saving Requests
Clicking Save and giving a request a name keeps it in Postman rather than losing it the moment the tab closes. A saved request on its own is useful, but Chapter 3 makes it much more useful — organizing saved requests into collections and reusing values across them with environments.
Putting It Together: Creating a Product
Method POST, URL https://api.example.com/products, a Content-Type: application/json header, and a JSON body — then reading a 201 Created response back:
The server echoed back the created product, now with an assigned id — confirming both that the request was understood and exactly what got stored.
💻 Coding Challenges
Challenge 1: Params or Body?
For each, say whether it belongs in query parameters or the request body, and why: (a) filtering a product list by category, (b) the full contents of a new blog post being created, (c) a page number for pagination.
Goal: Practice applying this chapter's params-vs-body distinction to concrete request-design decisions.
Challenge 2: Build a Request From a Description
Write out the method, URL with query parameters, headers, and body for: "create a new user with name 'Dana' and email 'dana@example.com', authenticating with a bearer token."
Goal: Practice assembling every piece of a request (method, URL, headers, body) from a plain-English description.
Challenge 3: Diagnose From Status Alone
Before even opening the response body, what does each of these status codes already tell you, and where should you look first: (a) 404, (b) 401, (c) 500?
Goal: Practice using the status code as a first diagnostic signal, per this chapter's "read status/time/size before the body" habit.
Typing a JSON object into the Body tab's raw editor doesn't automatically tell the server it's JSON — that's what the Content-Type: application/json header is for. Postman sets this header automatically when you select "JSON" from the raw body's format dropdown, but if that dropdown gets left on "Text" (or the header gets manually deleted), the server may receive a perfectly well-formed JSON body with no indication of its format, and either fail to parse it or silently treat every field as plain text. If a request with a body you're sure is correct keeps failing, checking the actual Content-Type header being sent is one of the first things worth verifying.
🎯 What's Next
The next chapter is Postman Collections & Environments — organizing saved requests into collections, reusing values across requests with environment variables, and chaining one request's response into the next.