Define a request contract, implement validation and authorization, then test observed latency, errors and recovery with a documented release procedure.
Write representative requests and responses for the first user task, including field types, required values, errors, pagination and version behavior. Specify the authorized caller and resource ownership rules. Format copied JSON examples for inspection, then validate them with the actual server schema and tests; a formatter is not a contract validator.
Choose storage from the actual consistency and access requirements, define constraints and transactions, and make retries safe where duplicate operations would matter. Validate request shape, content type, size and field bounds on the server. Review copied SQL for readability if applicable, but execute and inspect it only in the intended database environment.
Use a maintained authentication mechanism and validate its credentials or token claims as required by that mechanism. Enforce authorization for each operation and object, including cross-user access tests. Configure HTTPS and appropriate error/log behavior. Inspect copied response headers as supporting evidence; CORS or a header checklist does not establish server-side authorization.
Run integration tests for valid requests, invalid input, denied access, duplicate requests, missing resources and dependency failures. Test limits and timeout behavior with the actual storage and downstream services. Record request IDs and useful diagnostics while keeping credentials and sensitive payloads out of shared logs.
Define request mix, data size, concurrency, offered rate, duration and measurement boundaries. Collect actual completion counts, failures and complete latency samples. Use the timing tool’s measured-sample and observed-request modes for percentiles and rates; track pending work and timeouts separately. A serial stage sum cannot predict P99 or maximum capacity.
Package the tested version with configuration, migration order and a rollback or forward-repair procedure appropriate to the data changes. Define operational checks for latency, traffic, errors and saturation with an owner and action. Rehearse recovery in the intended test environment and retain contract, test and load evidence for the release review.
Format a copied JSON example for inspection; this does not query, validate a live API contract or configure a server. · Format copied JSON requests and responses from contract and failure-path tests for inspection. Run the tests and validate the API behavior in the actual application environment.
Write and download the task brief, measured results and handoff decisions as Markdown.
Format a copied SQL statement for review; this does not execute the query or verify its result.
Inspect copied HTTP response headers alongside the actual request and response; this tool does not fetch an endpoint.
Summarize actual latency observations or completed-request counts; keep serial stage assumptions separate.
Loading your checklist…
OWASP describes endpoint access control, method restrictions, input/content-type validation and careful errors and logging. Apply these to the concrete API operations.
Google SRE distinguishes latency, traffic, errors and saturation, and explains why measurements need useful operational interpretation.
Keep the following evidence with the actual version used for this task.
| Record | Include | Check |
|---|---|---|
| Contract | Version, examples, schema and ownership cases | Test actual server behavior |
| Load | Mix, offered load, interval, timing and outcomes | Do not infer capacity from a mean |
| Recovery | Migration, rollback/repair, owner and trigger | Rehearse the actual procedure |
Server processing time and client-observed latency can answer different questions.
A successful authenticated request does not demonstrate correct object ownership enforcement.