Understanding the API tester
A request, a response, and what to look at.
What an API tester does that curl doesn't, the headers most people forget, and the response shape that's worth a second look.
What it's for.
An API tester sends HTTP requests and shows the response in a structured way: status line, headers, body parsed by content-type, timing breakdown. The same job curl does in one line, but with persistent state — keep a list of requests, save environment variables, replay a previous request — and a UI that makes JSON readable. Postman built a billion-dollar company on this; the modern shape lives in lighter tools like Insomnia, Bruno, and in-browser testers.
The four headers that matter.
Content-Type declares the request body format — application/json, multipart/form-data, application/x-www-form-urlencoded. Mismatched between header and body is the single most common API bug. Accept declares what response format you want back. Authorization carries credentials — Bearer <token> for OAuth/JWT, Basic <base64> for HTTP Basic. User-Agent identifies the client; some APIs reject requests without one.
The methods, by intent.
GET for reads (idempotent, no body, cacheable). POST for creating resources or arbitrary actions (not idempotent, body, not cacheable). PUT for replacing a resource at a known URL (idempotent, body, "replace this whole thing"). PATCH for partial updates (often not idempotent, body, "apply this diff"). DELETE for removing a resource (idempotent). The verb in the request line is a hint about intent; servers can implement them however they want.
A worked test.
A simple POST to create a user: POST /api/users
Content-Type: application/json
Authorization: Bearer eyJhbGci...
{ "email": "a@b.com", "name": "Q" } The response: a status code (201 Created on success, 400 on validation failure, 401 on missing auth, 409 on conflict), response headers (often a Location header pointing to the new resource), and a body (the created object or an error description). All four pieces of the response carry information; tools that show only the body lose half the signal.
What to inspect
status + headers + body + timing
Each layer answers a different question.
201 + Location header + created entity + 45 ms
= Full picture
The status code matters more than you think.
200-class: success. 300-class: redirects (follow them or don't; some testers do automatically). 400-class: client error — the request was wrong. 500-class: server error — the request reached the server and something blew up. 422 is the conventional "valid request, business rule violation" code. 429 means rate-limited; the response usually has a Retry-After header. Reading the code first tells you what to do next.
CORS and the preflight.
Calling an API from a browser-based tester (rather than curl) involves CORS. For anything other than simple GET / POST with application/x-www-form-urlencoded, the browser sends a preflight OPTIONS request before the real one; if the server doesn't respond with the rightAccess-Control-Allow-* headers, the real request never runs. An API tester running in a browser will hit this; one running as a desktop app or browser extension typically bypasses CORS, which is why Postman started as a Chrome extension.
Environments and secrets.
A serious API tester separates the request from the environment — base URL, auth token, account IDs all live in a switchable environment so the same request can point at dev / staging / prod. Don't paste production tokens into a shared collection; treat each environment's secrets the same way you treat production environment variables.