← ClaudeAtlas

request-validationlisted

Validate requests at the boundary with schemas, reject unknown fields, and return errors clients can act on. Use when hardening API input handling or standardizing validation across endpoints.
Amey-Thakur/AI-SKILLS · ★ 4 · AI & Automation · score 77
Install: claude install-skill Amey-Thakur/AI-SKILLS
# Request validation Validate once, at the edge, into a typed value the rest of the code can trust. Everything past the boundary should be impossible to construct invalid. ## Method 1. **Schema-first, one schema per endpoint.** Define the request shape declaratively (JSON Schema via OpenAPI, zod, pydantic) and derive both the validator and the documentation from it. Hand-rolled if-chains drift from docs within a sprint. 2. **Parse, don't just check.** The validator's output is a typed object (trimmed strings, parsed dates, enum members), not the raw JSON plus a boolean. Downstream code taking `dict`/`any` re-validates forever. 3. **Reject unknown fields on writes.** A typo'd optional field (`descripton`) silently accepted is data loss the client discovers weeks later. Strictness on request bodies; tolerance is for what you read from others (be conservative in what you send, but validate what you accept). 4. **Layer the checks.** Shape and types (schema), then domain rules (ranges, formats, cross-field: `end > start`), then stateful rules (uniqueness, existence, permissions) inside the transaction where they are race-free. Shape failures are 400; semantic failures 422; state conflicts 409. 5. **Return all field errors at once, machine-readably.** Problem+json with a per-field list: `{"errors": [{"field": "email", "code": "format", "message": ...}]}`. One-error-at-a-time forces clients into a submit loop; codes let UIs local