API Testing Fundamentals Questions

Comprehensive coverage of testing application programming interfaces. Topics include HTTP methods and semantics, status codes, headers, payload formats such as JSON and XML, authentication and authorization mechanisms, request and response structure, and common API failure modes. Candidates should be able to design API test cases that include positive negative and boundary inputs, handle dynamic response data such as pagination and transient fields, and validate responses with assertions on status codes headers bodies schemas and response times. Additional areas include mocking and stubbing dependencies contract and schema validation, test data management and environment configuration, writing reusable programmatic API tests using tools such as Postman REST Assured and Python requests, and integrating API tests into continuous integration workflows for reliable automated verification.

MediumSystem Design

72 practiced

Describe how you would integrate API tests into a CI pipeline that requires environment configuration and secrets (API keys, certificates). Cover secure secret storage, parameterization of endpoints for different environments, choosing which suites run on PRs vs nightly runs, and how to avoid leaking secrets in logs.

EasyTechnical

56 practiced

Using Python requests, write a concise automated test that checks the health endpoint GET /health returns HTTP 200, Content-Type application/json, and a JSON body containing {"status": "ok"}. Assume base_url is provided. Include clear assertions and minimal error handling so the test is idempotent and suitable for CI (use pytest-style assertions).

Sample Answer

**Approach**- Simple, idempotent GET to /health using requests- Clear pytest-style assertions for status code, content-type, and JSON body- Minimal error handling to surface real failures in CI

**Test (pytest)**

python

import requests

def test_health_endpoint(base_url):
    """Verify GET /health returns 200, application/json and {'status': 'ok'}."""
    url = f"{base_url.rstrip('/')}/health"
    resp = requests.get(url, timeout=5)

    # HTTP status
    assert resp.status_code == 200, f"expected 200, got {resp.status_code}"

    # Content-Type header (allow charset if present)
    content_type = resp.headers.get("Content-Type", "")
    assert content_type.startswith("application/json"), f"unexpected Content-Type: {content_type}"

    # JSON body and exact content
    data = resp.json()
    assert isinstance(data, dict), "response JSON is not an object"
    assert data.get("status") == "ok", f"unexpected status value: {data}"

**Notes**- timeout prevents hanging in CI- rstrip ensures proper URL joining- Using assertions makes failures explicit for CI pipelines

MediumTechnical

64 practiced

Design automated tests to verify API rate limiting behavior and Retry-After header semantics without causing harm to production systems. Include the load patterns you would generate, safe test windows, how to assert both soft and hard limits, and how to make tests both reliable and non-invasive.

MediumTechnical

73 practiced

Explain how you would implement consumer-driven contract testing with Pact across microservices. Describe the typical workflow: consumer test creation that generates a pact, publishing to a broker, provider verification against provider builds, handling versioning and tagging, and how to avoid false positives/negatives in CI pipelines.

Sample Answer

**Brief overview / goal**Show how Pact implements consumer-driven contracts so consumers drive API expectations, providers verify they still satisfy them, and CI enforces safe deployment.

**Typical workflow**- Consumer test creation - Write consumer-side tests (e.g., pact-js / pact-jvm) that exercise expected interactions. - Tests generate a pact file describing requests/expected responses.- Publish to Pact Broker - After a successful consumer build, run: publish pact file to Broker with metadata (consumer version, git sha, branch). - Tag pacts (e.g., "feature/123", "main", "staging") so environments and branches are clear.- Provider verification - Provider CI fetches relevant pacts from Broker (by consumer, provider, or tag). - Run Pact provider verification as part of provider build; provider spins up test instance, seeds provider state for each "provider state" defined in pact. - Publish verification results back to Broker (pass/fail, provider version).- Deployment gating - Use Broker API or "can-i-deploy" to decide if a provider version can be deployed to an environment based on verification matrix and tags.

**Versioning & tagging strategy**- Use semantic consumer versions and Git SHAs.- Tag pacts by branch/environment: "main", "release-1.2", "prod", "staging".- On merge to main, re-publish pact tagged "main"; for releases tag release-specific.- Provider selects pacts to verify by tag(s) matching target environment.

**Avoiding false positives / negatives in CI**- Use explicit provider states and deterministic test setup: provider verification must call provider state setup hooks to prepare DB/data; avoid brittle shared state.- Run provider verification against an isolated test instance (ephemeral DB, containers) to avoid environmental drift.- Make interactions strict: verify request/response bodies and headers you depend on; avoid overbroad matchers that mask regressions.- Reduce flakiness: increase timeouts for network calls, retry transient setup steps, and fail fast on setup errors.- Separate contract tests from end-to-end integration tests in pipeline: run contract verifications early (fast) and integration tests in a later stage.- CI orchestration: - Consumer pipeline: run unit+contract tests -> publish pacts -> tag. - Provider pipeline: fetch pacts by tag -> run provider verification -> publish results -> run integration tests. - Use "can-i-deploy" to gate deployment; only allow deploy if all required consumer tags have successful verification by provider version.- Monitoring and observability: surface Broker verification results and failures in pipelines, add issue creation hooks/webhooks for failures to avoid ignored regressions.

**Example commands (conceptual)**- Publish: pact-broker publish path/to/pacts --consumer-app-version 1.2.3 --tag main- Provider verify: pact-provider-verifier --provider-base-url http://localhost:8080 --pact-broker-base-url https://broker --consumer-version-tag main- Can I deploy: pact-broker can-i-deploy --pacticipant Provider --version 2.0.0 --to production

Following this pattern ensures the consumer API expectations drive provider behavior, versioning and tags map to environments/releases, and CI practices minimize false positives/negatives through isolation, deterministic state setup, and clear gating.

EasyTechnical

71 practiced

Explain how you would test caching semantics for an API resource that supports ETag and Last-Modified headers. Describe a sequence of automated requests and assertions to verify correct 304 Not Modified responses, ETag change after updates, and correct Cache-Control directives.

Unlock Full Question Bank

Get access to hundreds of API Testing Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.