Core automation track

API Testing

Contract-first validation that catches bugs before the UI exists.

What this track covers

REST conceptsHTTP methodsStatus codesHeadersAuthentication & OAuth2JSON & JSONPathSchema validationNegative testingAPI chainingPerformance of endpoints

What to assert on every response

A complete API check covers status, schema, business fields, headers and response time — not just 200.

Why it is required: 'I assert the status code' is the answer that ends interviews early.

Example: A full assertion block for GET /orders/{id}.

java

1given().spec(SPEC).pathParam("id", 91)
2.when().get("/orders/{id}")
3.then()
4    .statusCode(200)
5    .contentType(ContentType.JSON)
6    .header("Cache-Control", notNullValue())
7    .body(matchesJsonSchemaInClasspath("schemas/order.json"))
8    .body("status", equalTo("PLACED"))
9    .body("items.size()", greaterThan(0))
10    .time(lessThan(1500L));

Expected result

Contract, business logic, headers and latency validated in one call.

Common mistakes

Only asserting the status code
Ignoring negative cases (401, 403, 404, 422)
Hardcoded ids that only exist in one environment

What do you validate in an API response beyond the status code?

Related interview questions

Open bank

How do you validate a nested JSON response in REST Assured?
Use JSONPath expressions in body() matchers, or deserialize into a POJO and assert on typed fields.
How do you chain API requests (use a response value in the next request)?
extract() the value from the first response and pass it into the next request.
What is the difference between PUT and PATCH? When do you test each?
PUT replaces the whole resource and is idempotent; PATCH applies a partial update. Both should be idempotent-safe, but PATCH bodies are diffs.
Which HTTP status codes must an API tester know cold, and what do you assert beyond them?
200/201/202, 204, 301/302, 400, 401 vs 403, 404, 409, 422, 429, 500/502/503 — and beyond the code you assert body schema, headers, and side effects.
How do you test idempotency and retries?
Send the same request twice with the same Idempotency-Key and assert one resource is created; GET, PUT and DELETE must be naturally idempotent, POST needs a key.
How do you validate a response schema, and why is that better than field-by-field asserts?
Validate against a JSON Schema (or the OpenAPI spec) so types, required fields and enums are checked in one assertion that fails when the contract drifts.

Quick reference available

Open the matching cheat sheet for last-minute revision.