JSON Schema Validator

JSON Schema is a JSON vocabulary for describing the shape of other JSON documents: which properties are required, what types values must be, ranges for numbers, patterns for strings, array item shapes and nesting rules. The schema is itself JSON, so it lives in the same tooling ecosystem as the data it describes — versionable in git, editable in any JSON editor, and consumable by validators in every language.

It matters most at integration boundaries, where one system's output becomes another's input and the contract between them lives only in documentation until something validates it. A webhook payload, a config file, an API response, a form submission — all are cases where "should have a string id and a positive price" needs to be machine-checkable, not a hope expressed in a README.

A validator (Ajv in this tool) compiles the schema into a fast check function, then walks the document alongside it: for each keyword in the schema, the corresponding value in the data is tested — type: "integer" against the value, required against the object's keys, pattern against the string. A value that passes every applicable keyword is valid; the first failure produces an error with the exact location and reason.

The error path (.items[2].price) is the pointer into the document where the failure occurred, and the keyword that failed tells you what rule broke — type, required, minimum, pattern. Good validators collect all errors in one pass instead of failing on the first, so a caller can fix everything at once rather than discovering one problem per round-trip. Keyword evaluation is composable: allOf, anyOf, oneOf and not combine subschemas with boolean logic, which is how complex constraints are built.

The workhorse keywords: type (string, number, integer, boolean, array, object, null), required (array of property names that must be present), properties (a schema for each named property), additionalProperties (false or a schema for anything not listed), items (schema for array elements) and enum (value must be one of a fixed list). Numbers get minimum, maximum, exclusiveMinimum/exclusiveMaximum and multipleOf; strings get minLength, maxLength and pattern (a regular expression); arrays get minItems and uniqueItems.

Two patterns are worth internalizing. First, the "required but nullable" combo — type: ["string", "null"] with minLength — which models optional-but-typed fields correctly, unlike an omitted required entry which would accept an absent field. Second, additionalProperties: false, which turns a schema into a closed contract: unknown keys become errors instead of being silently ignored, which is what catches API drift in both directions.

Client-side validation is for humans: instant feedback in a form, catching a typo before the request is made, and it runs where Ajv (the validator used here) does — entirely in the browser, with nothing sent anywhere. It improves UX and nothing else; a user can bypass the browser entirely, so client-side checks must never be the only line of defense.

Server-side validation is for trust: every request that reaches your API must be validated against the same schema before the data touches business logic, because the caller could be anyone. The two layers use the same schema — that's the point of a shared contract — and disagree only in consequence: client-side failures produce friendly messages, server-side failures produce 400s, and untrusted data that skips both produces the confusing deep-stack bugs that schema validation exists to prevent.

Design schemas for the consumer's reality, not the producer's: validate at the boundary (where data enters your system), not at the edges of every internal function where the data is already known-good. Version schemas alongside the data they describe — a schema change is an API change, and draft versioning ($schema: "https://json-schema.org/draft/2020-12/schema") pins the exact rule set, since keywords have shifted meaning across drafts.

Keep schemas as permissive as the contract allows and as strict as the data requires: over-strict schemas (pattern requirements on free-text fields, closed additionalProperties on extensible objects) break legitimate producers, while under-strict schemas let bad data through to fail confusingly later. Use descriptions and examples inside the schema — they're part of the JSON Schema spec and make the contract self-documenting — and treat validation errors as a product surface: a precise error with a path is a feature, not just a failure mode.