Section 2 Review
You've finished Data, Contracts, and Test Cases, the second section of API Testing. This page is a dedicated recap — bookmark it as a fast reference, separate from the modules themselves.
Section Summary
✔ API Requests and Responses — following a request through its full lifecycle, and recognizing the three response patterns (success, empty, error) that recur across nearly every API ✔ Headers, Parameters, and Payload Validation — treating headers, path/query parameters, and the request body as three independent validation surfaces, each with its own failure modes ✔ Data Validation and Response Verification — validating a response in layers (structure, type, format, enum, cross-field), catching defects invisible to a structural check alone
How they build on each other: Module 4 established the request/response unit and its recurring patterns. Module 5 broke the request side down into its three independent validation surfaces. Module 6 closed the section by going deep on the response side — not just "is the body structurally valid," but "is the data inside it actually correct," down to cross-field business rules a single-field check can't catch alone.
Validation Layer Reference Matrix
A quick reference for what each layer catches:
| Layer | Catches | Misses |
|---|---|---|
| Structure | A field is missing entirely | A present field with the wrong value |
| Type | A field has the wrong kind of value (string vs. number) | A correctly-typed value with wrong precision or format |
| Format | Wrong decimal precision, invalid date format, pattern mismatch | A value outside a documented enum |
| Enum | A value outside its documented allowed set | Two fields that individually validate but disagree with each other |
| Cross-Field | A calculated total, timestamp ordering, or status/field mismatch | Nothing further within data validation — this is the deepest layer |
Section 2 Knowledge Check
Five realistic scenarios. For each, identify which validation surface or layer applies, and what specifically to check. No answers are provided here. Solutions: Section 2 Solutions.
Scenario 1: AtlasBank's POST /api/v1/accounts/{accountId}/transfers test data was copied from an existing test case and modified — the new test is meant to verify a transfer with no memo, but the copied request still has "memo": "" left over from the original.
Scenario 2: AtlasBank's GET /api/v1/accounts/{accountId}/beneficiaries?status=inactive returns 200 OK with a full beneficiary list — identical to what's returned when status is omitted entirely.
Scenario 3: AtlasBank's card-details response includes "cardNumber": "****4821" and "expiryDate": "2027-13".
Scenario 4: AtlasBank's loan-application response includes principalAmount: 10000.00, interestRate: 0.05, termMonths: 12, and monthlyPayment: 856.07 — verified only with this one round-number test case.
Scenario 5: AtlasBank's statement-download error response returns 500 Internal Server Error with Content-Type: text/plain and a raw stack trace, while every successful statement response returns Content-Type: application/json.
Continue to Section 3
Auth and Access Control, starting with API Authentication — where this section's request/response and data-validation literacy gets applied to authentication tokens, authorization boundaries, and rate limiting.