Lesson 1: Your First Schema
JSON Schema is a JSON document that describes the shape of another JSON document — it is a contract that your data must satisfy. The "type" keyword specifies what kind of value is allowed: string, number, boolean, array, object, or null. The "required" array lists the property names that must be present in the object; omitting any of them causes a validation error. Finally, setting "additionalProperties" to false locks the schema so that no extra properties beyond those declared in "properties" are permitted.
Why This Matters
Every API, config file, and message queue payload is really just JSON with an implicit shape — JSON Schema makes that shape explicit and machine-checkable. Instead of discovering a missing "email" field when your code throws a TypeError three functions deep, validation catches it at the boundary, with a precise error pointing at the exact field. This is also the foundation for generating API docs, TypeScript types, and mock data from a single source of truth, so the schema you write in this lesson is the same kind of document used to define OpenAPI request bodies, Kafka message contracts, and CLI config files in production systems.
Common Mistakes
- ✕ Assuming "properties" alone restricts the object to those fields.By default JSON Schema allows any extra properties. If you don't also set "additionalProperties": false, a typo like "naem" instead of "name" will pass validation silently as an unrecognized extra field.
- ✕ Listing a field in "required" without defining it in "properties".This is technically valid — the field must be present, but its value is never type-checked. Always define a schema for every property you require.
- ✕ Using "type": "number" for values that should only ever be whole numbers, like an id or a count.Use "type": "integer" instead so that 4.5 correctly fails validation for a field like "age" or "quantity".
- ✕ Forgetting that JSON Schema has no concept of "optional but defaulted".A "default" keyword is only a documentation/tooling hint — it does not get injected into the data during validation, so an omitted optional field stays absent, not defaulted.
Challenge
Add an 'email' field (string, required) to the schema, then add it to the data.