Skip to main content

Module 6 · API testing

HTTP, methods and status codes

The request–response model every API test builds on.

About 11 min reading and 10 min practice (estimates)

Loading progress…

Read

Learning objectives

  • Read an HTTP request and response.
  • Explain what GET, POST, PUT, PATCH and DELETE are for, and which are safe or idempotent.
  • Interpret the main status code classes.

Explanation

An API request has a method, a URL, headers and sometimes a body. The response has a status code, headers and usually a body — often JSON. API tests send requests directly, which makes them faster and more precise than going through the user interface.

MethodTypical useSafeIdempotent
GETRead a resourceYesYes
POSTCreate something or trigger an actionNoNo
PUTReplace a resourceNoYes
PATCHChange part of a resourceNoNot necessarily
DELETERemove a resourceNoYes

Safe means the request isn't meant to change anything on the server. Idempotent means sending it twice has the same intended effect as sending it once — important when clients retry after a timeout.

  • 2xx success — 200 OK, 201 Created (often with a Location header), 204 No Content.
  • 3xx redirection — the resource is elsewhere.
  • 4xx client error — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Content, 429 Too Many Requests.
  • 5xx server error — 500 Internal Server Error, 503 Service Unavailable. A 5xx caused by user input is a bug: the server should reject bad input with a 4xx.

Example: reading the product list

Illustrative — not a working endpoint.

GET /v1/products?category=ceramics HTTP/1.1
Host: api.dar-al-souq.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "items": [
    { "id": "incense-burner", "price": "6.500", "currency": "OMR" },
    { "id": "coffee-cups",    "price": "8.250", "currency": "OMR" },
    { "id": "serving-bowl",   "price": "12.000", "currency": "OMR" }
  ],
  "count": 3
}
Illustrative: a fictional API for the training shop (the .example domain never resolves).

Common mistakes

  • Treating any 200 as success without reading the body.
  • Accepting a 500 for invalid input as "expected".
  • Retrying non-idempotent POST requests in tests without checking for duplicates.

Try

Practise what you just read. Answers are checked here; nothing is graded publicly or counts toward Bug Arena.

Exercise

A POST /v1/orders request with valid data creates an order. Which response is most appropriate?

Choose one answer.

Review

Check yourself — you should now be able to:

  • Read an HTTP request and response.
  • Explain what GET, POST, PUT, PATCH and DELETE are for, and which are safe or idempotent.
  • Interpret the main status code classes.

Practise in QA Lab

References

Continue

When you’re ready, mark the lesson complete in the Try step and move on.

Marked as read when you reach the end of the lesson.