What a request and a response consist of
A request = a method + a URL + headers + a body. A response = a status code + headers + a body.
POST https://api.bank.test/v1/accounts/42/transfers?dryRun=false
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Idempotency-Key: 7f3c-...
{ "toAccount": "UA21...", "amount": 150.00, "currency": "UAH" }
Here all the parts are visible: the POST method, the base URL with the API version, the path to the resource with the path parameter 42, the query parameter dryRun, three headers and a JSON body. Each of these parts is a separate source of test cases, so when analysing a new endpoint I break down the request exactly like this, piece by piece.
Path vs query. The path points to a specific resource (/users/42), the query filters or configures the output (/users?status=active&page=2). The rule is simple: if without the parameter the resource loses meaning, it is path; if it is an output option, it is query.
In an interview: A request consists of a method, a URL, headers and a body, and a response of a status code, headers and a body. A path parameter identifies a resource, and a query parameter filters, sorts or paginates the output.
What to check in each part
This table is a ready plan of negative and positive cases for any endpoint.
| Part | Example | What to check |
|---|
| Base URL | https://api.bank.test/v1 | Move into the variable {{baseUrl}} |
| Path | /accounts/42/transfers | Someone else's or a nonexistent id gives 403 or 404 |
| Path param | 42 | An invalid type (abc) gives 400 |
| Query param | ?dryRun=false | Filters, pagination, sorting |
| Headers | Authorization, Content-Type, Accept | Without a token 401; a wrong Content-Type 415 |
| Body | JSON with fields | Required fields, types, boundaries |
| Status | 201 Created | The code matches the documentation |
| Response headers | Content-Type, Location | Content type, cache, CORS |
| Response body | { "id": "tr_91", "status": "pending" } | Structure, types, values, no extra sensitive fields |
| Time | 180 ms | Within the SLA |
Note the Location in a creation response: it often holds the URL of the new resource, and it is convenient to use for the next GET. And checking for "no extra sensitive fields" is not a formality: if a response has a password hash or a full card number, that is already a security defect, even when everything else is right.
In an interview: I go through a request part by part: the URL and path parameters, the query, headers, body, and in the response the status, headers, body and time. Each part has its own negative cases, for example an invalid id type gives 400, and a wrong Content-Type gives 415.