Requests, responses and REST basics for testers

Every API test sends a request and checks a response. Knowing what each part means lets you predict the correct result and recognise when the server is wrong.

Parts of a request

POST /api/users HTTP/1.1
Host: example.test
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"name": "Asha", "email": "asha@example.test"}

• Method: what to do. GET reads, POST creates, PUT replaces, PATCH partly updates, DELETE removes.
• URL: which resource. In /users/42?status=active, 42 is a path parameter and status is a query parameter.
• Headers: extra information. Content-Type describes the body you send; Accept says what format you want back; Authorization carries credentials.
• Body: the data, usually JSON, for POST, PUT and PATCH.

Status code families

• 2xx success: 200 OK, 201 Created, 204 No Content.
• 3xx redirection: the resource is elsewhere.
• 4xx client error: 400 bad request, 401 not authenticated, 403 not allowed, 404 not found, 409 conflict, 422 validation failed (used by some APIs).
• 5xx server error: 500 internal error, 503 service unavailable.

A useful rule: if your input was wrong, expect 4xx. If you see 5xx after bad input, the server did not handle it and that is a defect.

REST conventions and idempotency

REST APIs treat data as resources with nouns in the URL, such as /orders and /orders/17, and use methods for the action, instead of URLs like /getOrder.

A method is idempotent if sending the same request many times leaves the server in the same state as sending it once. GET, PUT and DELETE are idempotent; POST is not, because repeating it can create duplicates. This matters when clients retry after a timeout, so testers often check what happens when the same POST is sent twice.

JSON essentials

Valid JSON uses double quotes for keys and strings, lowercase true, false and null, and no trailing commas. Arrays are zero-indexed, so data.items[1] is the second item.

Habit to build: before sending a request, write down the status code and key body fields you expect. Then compare them with what comes back.