What are the key things you validate in an API test?

Five layers of validation: (1) Status code — correct for the scenario (200, 201, 400, 404, etc.). (2) Response body — correct data, structure, and types. (3) Headers — content-type, cache-control, security headers. (4) Performance — response time within SLA. (5) Error handling — proper error messages and codes for invalid inputs. Also validate idempotency for PUT/DELETE and pagination for list endpoints.

Explain the difference between REST and GraphQL. How does testing differ?

REST: fixed endpoints per resource, HTTP verbs for CRUD, multiple round trips for related data. GraphQL: single endpoint, client specifies exactly what data it needs, fewer round trips. Testing differences: REST — test each endpoint/method combo. GraphQL — test queries, mutations, and subscriptions; validate query depth limits, authorization per field, and N+1 query performance. Both need schema validation, auth testing, and error handling tests.

How do you test API authentication and authorization?

Authentication tests: valid token returns 200, expired token returns 401, missing token returns 401, malformed token returns 401. Authorization tests: user A cannot access user B's resources (403), role-based access (admin vs. user), resource-level permissions. Test with multiple user roles and verify each endpoint enforces the correct access level. Also test token refresh flows and session expiration.

What is contract testing and how does Pact work?

Contract testing verifies that a consumer and provider agree on the API interface without needing both running simultaneously. Pact workflow: (1) Consumer writes tests defining expected requests/responses — generates a "pact" (contract file). (2) Provider runs the pact against its real implementation to verify compliance. (3) Pact Broker stores contracts and verification results. Benefits: catches integration breaks in CI without deploying all services. Essential for microservices where full integration environments are expensive.

How do you test API rate limiting and throttling?

Send requests at the documented rate limit boundary — verify that the Nth+1 request returns 429 (Too Many Requests) with a Retry-After header. Test reset behavior — after the window expires, requests should succeed again. Verify rate limit headers in responses (X-RateLimit-Limit, X-RateLimit-Remaining). Test across different API keys and IP addresses. Use tools like k6 or Artillery for load-based rate limit testing.

What HTTP status codes should a QA engineer know, and when is each used?

200 OK (success), 201 Created (resource created), 204 No Content (success, no body — common for DELETE). 301/302 Redirects. 400 Bad Request (client error — invalid input), 401 Unauthorized (not authenticated), 403 Forbidden (authenticated but not authorized), 404 Not Found, 409 Conflict (duplicate resource), 422 Unprocessable Entity (validation failed). 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable. Know these by heart — every API test validates status codes.

How do you validate JSON schema in API tests?

Use JSON Schema validation libraries (Ajv for JavaScript, jsonschema for Python) to verify response structure: required fields present, correct data types, string formats (email, date-time, UUID), enum values, and array item types. Store schemas as files and validate every API response against them. This catches breaking changes early — a removed field or type change fails the schema check even if the endpoint returns 200.

How do you handle API test data setup and teardown?

Setup: create test data via API calls (POST endpoints) before each test — don't rely on pre-existing data. Teardown: delete created data after each test. Use unique identifiers (UUIDs, timestamps) to avoid conflicts in parallel runs. For complex scenarios, use database seeding or transaction rollbacks. In frameworks like Playwright, use `beforeAll`/`afterAll` for shared setup and `beforeEach`/`afterEach` for test-specific data.

What is the difference between positive and negative API testing? Give examples.

Positive testing verifies the API works correctly with valid inputs: creating a user with all required fields returns 201. Negative testing verifies graceful handling of invalid inputs: missing required fields (400), invalid email format (422), SQL injection strings (400, not 500), extremely long strings (400), wrong data types (422). A thorough API test suite has more negative tests than positive — the happy path is one path, but there are many ways to fail.

How do you test webhooks and asynchronous API operations?

For webhooks: set up a test endpoint (using tools like webhook.site or a local server) to receive webhook payloads. Trigger the event, then poll your endpoint to verify the webhook arrived with the correct payload, headers, and timing. For async operations: call the initiating endpoint, then poll the status endpoint until completion (with timeout). Verify the final state and any side effects. Test retry behavior for failed webhook deliveries.