Skip to content
SDETRole
SDETRole

Learning path 03 · Beginner → Advanced

API Testing

Understand HTTP deeply enough to design API tests, then automate them. Covers REST semantics, JSON, authentication, Postman, REST Assured, assertions and contract testing.

Start the path

0/9 lessons completed

What you will be able to do

  • Read any HTTP exchange: method, URL, status code, headers and body
  • Explain REST resources, idempotency, pagination and versioning, and what each means for tests
  • Query JSON with JSONPath and validate its shape with JSON Schema
  • Test API authentication, including the negative cases that find real bugs
  • Automate API checks in Postman with Newman, in Java with REST Assured and in TypeScript with Playwright
  • Decide what an API test should assert without making it brittle
  • Describe how consumer-driven contract testing with Pact prevents breaking changes

Prerequisites

  • Basic testing vocabulary
  • Some JavaScript or Java helps for the automation lessons, but the first four lessons need no code

Who this path is for

Testers who have used Postman but want to design API tests properly, and automation engineers adding an API layer to a UI-heavy suite.

Syllabus: 9 lessons

  1. 01 HTTP Fundamentals Requests, responses, methods, status codes and headers: the HTTP model every API tester needs, with examples you can try in the browser.
  2. 02 REST APIs Explained Resources, URIs, CRUD mapping, statelessness, pagination, filtering and versioning: how REST APIs are designed and what that means for the tests you write.
  3. 03 JSON for Testers JSON syntax and data types, the mistakes that break payloads, querying with JSONPath, validating with JSON Schema and asserting on JSON in API tests.
  4. 04 API Authentication API keys, Basic auth, bearer tokens, JWTs, OAuth 2.0 and sessions: how APIs identify callers, and the negative tests that find real authentication bugs.
  5. 05 Postman: Collections, Environments, Scripts Organise requests into collections, switch targets with environments, write pm.test scripts, chain a login token and run the lot in CI with Newman.
  6. 06 API Automation with Playwright Test REST APIs with Playwright's request fixture and APIRequestContext: configuration, assertions, auth fixtures, and using the API to set up UI tests.
  7. 07 REST Assured Basics Write readable Java API tests with REST Assured 5: given/when/then, GPath body assertions with Hamcrest, specifications, extracting values and JSON Schema checks.
  8. 08 Designing API Assertions Decide what an API test should check: status, headers, schema, values, business rules and side effects, without writing brittle tests that break on every harmless change.
  9. 09 Contract Testing Catch breaking API changes before deployment with consumer-driven contracts: how Pact works, provider states, verification, the broker and can-i-deploy.

How the API testing path is structured

The first half is protocol knowledge, which is what separates a tester who sends requests from one who designs API tests. HTTP fundamentals, REST APIs explained, JSON for testers and API authentication explain status codes, idempotency, payloads and tokens. The second half turns that into automation with Postman, REST Assured and Playwright API automation, then finishes with assertion design and contract testing.

Send real requests while you learn

The API testing playground is connected to a practice API on this site with validation errors, bearer-token auth, pagination headers and RFC 9457 problem responses. Use it during the HTTP and REST lessons to see a 422 with field errors, a 409 conflict or a 401 without a token. Once you reach the Playwright lesson, the cart API contract challenge runs your request tests against a working API and against versions with planted bugs, so a test that asserts too little fails the challenge.

Use the cURL generator to turn a request into a command you can rerun from a terminal, and the JSONPath tester to work out expressions before you put them into assertions.

Common API testing mistakes

  • Asserting only the status code. A 200 with the wrong body is still a bug; check the schema and the values that matter.
  • Asserting every field, including timestamps and generated IDs, so the test breaks on harmless changes.
  • Skipping negative auth tests: expired tokens, another user's resource (IDOR) and missing scopes.
  • Treating PUT and PATCH as interchangeable. Idempotency affects retries and therefore test design.
  • Leaving test data behind. Create what you need through the API and clean it up, or use unique data per run.

Interview expectations and study plan

API rounds usually combine theory ("what is the difference between 401 and 403?") with a design question ("how would you test this endpoint?") and sometimes live automation. Work through the API testing interview questions after the REST lesson and the Postman and REST Assured questions after their lessons. At around 45 minutes a day the path takes three to four weeks. Keep the HTTP cheat sheet and the API testing checklist open as references.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →