API Testing

Replacing a real API with a controlled stand-in that returns scripted responses. Lets you test client behaviour against edge cases (5xx, slow responses, malformed payloads) that the real API rarely produces on demand.

The process of verifying who a caller is. Common schemes: API key, Bearer token, OAuth 2.0, mutual TLS. Distinct from authorisation, which decides what they're allowed to do.

Verifying that two services agree on the shape of the messages they exchange. Catches breaking API changes without expensive end-to-end tests across multiple deployed services.

Cross-Origin Resource Sharing — a browser security mechanism that restricts web pages from making HTTP requests to a domain different from the one that served the page. The browser preflight-checks cross-origin requests by sending an `OPTIONS` request; the server responds with `Access-Control-Allow-Origin` (and related) headers to grant or deny access. For API testers: misconfigured CORS is a common security vulnerability, and missing CORS headers cause silent failures in browser-based test environments.

A specific URL exposed by an API that accepts requests and returns responses. Defined by its path, HTTP method, and contract.

A retry delay strategy where each successive attempt waits twice as long as the previous one: delay = base × 2^(attempt−1). Attempt 1 waits base ms, attempt 2 waits 2×base, attempt 3 waits 4×base. Prevents thundering-herd problems by spreading out retry load on a recovering service. Often combined with jitter (a random offset within the delay range) to avoid synchronised retry storms from multiple clients.

A query mechanism that returns only records matching specified criteria — by category, date range, status, or user-defined attributes. Testing concerns include: single and combined filters, filters that return zero results, filters with special characters, case sensitivity, AND vs OR logic, and whether filter state is preserved in the URL (enabling deep-linking and back-button behaviour). Also verify that filtered counts match the displayed results and that applying a filter to a paginated list resets to page one.

A search mechanism that matches query terms against the full content of indexed documents, not just field-level equality. Testing concerns include: relevance ranking (are the most relevant results first?), partial-word and stemming behaviour, special-character handling, empty query results, very long queries, and search across multiple fields. Also verify performance under load — full-text search is computationally heavier than simple filtering — and that results are consistent when the same search is repeated.

A query language and runtime for APIs where clients specify exactly which fields they want in a single request. Replaces multiple REST endpoints with one flexible endpoint and a typed schema.

Google's open-source Remote Procedure Call framework. gRPC uses HTTP/2 for transport and Protocol Buffers for serialisation, making it significantly faster and more bandwidth-efficient than JSON over REST. Clients call server methods directly using generated stubs — there are no URLs or HTTP verbs to reason about. gRPC supports four streaming modes: unary (one request, one response), server-side streaming, client-side streaming, and bidirectional streaming, each introducing distinct test scenarios.

A key-value metadata field attached to an HTTP request or response, transmitted before the body. Request headers describe the client and request context (User-Agent, Accept, Content-Type, Authorization, Cookie); response headers describe the server's response and instruct the client (Content-Type, Set-Cookie, Cache-Control, CORS access-control headers, security headers). Header names are case-insensitive. QA testing checklist: assert Content-Type matches the body format; verify security headers are present on responses (HSTS, CSP, X-Frame-Options, X-Content-Type-Options); confirm sensitive request headers (Authorization, Cookie) are not logged or exposed in error responses; verify CORS headers permit only expected origins.

A property of an operation where calling it once and calling it many times produce the same effect. Critical for safe retries — GET, PUT, and DELETE are idempotent in HTTP semantics; POST is not. Tests should verify duplicate requests don't double-charge, double-create, or double-send.

An operation is idempotent if calling it multiple times produces the same result as calling it once. In REST, GET, PUT, DELETE, and HEAD are designed to be idempotent; POST is not. Idempotency matters for testing because you can safely retry a failed test step without fear of side effects. It also matters for test design: idempotent API calls make it straightforward to reset state between test runs.

A JSON-based vocabulary for describing the structure, constraints, and data types of JSON documents. A schema specifies required fields, allowed types (string, number, boolean, array, object), string patterns, numeric ranges, and nested object shapes. In API testing, JSON Schema validation is used to assert that every response conforms to the expected contract — catching breaking changes the moment a field is renamed, a type changes, or a required field goes missing.

A label (e.g. application/json, image/png, text/csv) that declares the format of a file or HTTP body, carried in the Content-Type header. Testing concerns include: mismatches between the declared type and actual content (a server returning HTML with Content-Type: application/json), frontend code that trusts the extension rather than the declared type, and upload endpoints that validate MIME type purely client-side — allowing an attacker to spoof it. Test by sending requests with mismatched Content-Type headers and verify the server rejects or handles them safely.

A language-agnostic specification format for describing REST APIs — formerly called Swagger. An OpenAPI document (written in YAML or JSON) defines every endpoint, its HTTP method, request parameters, request body schema, possible responses, and authentication requirements. Teams use OpenAPI to generate client SDKs, server stubs, interactive documentation (Swagger UI), and automated test cases. Contract testing tools like Schemathesis derive hundreds of fuzz tests from a single spec.

A mechanism for breaking a large result set into discrete pages, returned via page/offset parameters or a cursor. Common bugs include off-by-one errors at page boundaries (last item on page N appearing as first item on page N+1), incorrect total-count values, empty last pages, and results changing between pages when the underlying data is modified mid-session. Test with dataset sizes that exercise boundaries: exactly one page, exactly one item, zero items, and a non-integer number of full pages.

The data carried in the body of a request or response, typically JSON or XML. The 'what' an HTTP message is communicating — distinct from headers and metadata.

Google's binary serialisation format. You define message schemas in `.proto` files; the `protoc` compiler generates strongly-typed serialisation/deserialisation code for any supported language. Protobuf messages are smaller and faster to parse than equivalent JSON but are not human-readable without the `.proto` schema file. In QA, `.proto` files serve as the contract — tests can validate that serialised messages match the schema exactly, including field types and required fields.

An API protection mechanism that caps how many requests a client can make in a window. Tests should verify both the limit threshold and the response when exceeded (typically HTTP 429 with Retry-After).

Representational State Transfer — an architectural style for HTTP APIs where resources are addressed by URLs and manipulated via standard HTTP verbs (GET, POST, PUT, DELETE). The dominant API style for over a decade.

An application-level strategy for automatically re-issuing a failed HTTP request or operation, using a backoff delay between attempts to avoid overwhelming a recovering service. A retry policy defines: maximum retry count, delay strategy (fixed, linear, or exponential backoff), optional jitter, per-attempt timeout, and total deadline. Retries must only be applied to idempotent operations — retrying a non-idempotent request (such as a payment) can cause duplicate actions.

Asserting that an API request or response matches a defined schema (JSON Schema, OpenAPI, Protobuf). Catches contract drift the moment it appears, without writing field-by-field assertions in every test.

Simulating the behaviour of dependent services — including timing, errors, and stateful protocols — that aren't available, are too costly to call, or are still being built. Broader than API mocking: covers protocols beyond HTTP and stateful interactions.

Simple Mail Transfer Protocol — the standard protocol for sending email between servers. In a testing context, SMTP is the delivery layer beneath features like email verification, password reset, and notifications. Test concerns include: whether emails are actually sent (a stub or real SMTP endpoint must be in the test environment), correct recipient address, subject, body, and link content, and that sensitive tokens in email links are single-use and expire. Tools like Mailhog or Mailtrap provide a local SMTP server that captures outbound email without delivering it.

Ordering a result set by one or more fields, in ascending or descending direction. Testing concerns include: correct ordering for string (locale-aware), numeric, and date fields; stable sort behaviour when two records share the same sort key; sort direction toggle (ascending → descending); sort combined with filtering and pagination; and null/empty values (do they sort first or last, consistently?). Also verify that the default sort order is documented and stable across responses.

A three-digit HTTP response code indicating outcome — 2xx success, 3xx redirect, 4xx client error, 5xx server error. The first signal an API test asserts on.

A maximum duration allowed for an operation to complete before it is considered failed. In API and network testing: connection timeout (time to establish the TCP connection), read timeout (time to receive the full response after connecting), and total deadline (aggregate across all retry attempts). A timed-out request differs from a failed request — the status code, error type, and retry behaviour differ and must each be tested explicitly.

An HTTP callback that a service POSTs to a registered URL when an event occurs — Stripe payment succeeded, GitHub PR merged. Tests must handle delivery delays, retries, signature verification, and out-of-order events.