JSON tools
JSON Schema Rules: Types, Required Fields and Numeric Boundaries
Write and test a small JSON Schema contract, distinguish presence from null, and turn business requirements into explicit assertions.
Translate a concrete requirement into assertions
JSON Schema rules describe which JSON instances satisfy a contract. Start with the data meaning rather than copying every keyword from a large example. For a reservation request, suppose the item code must be a nonempty string, the seat count must be an integer between one and eight, and an optional note may be either a string or null.
The following draft-07 example states those conditions explicitly. It also rejects properties not listed in this object schema. That choice is appropriate for this illustrative request contract; a forward-compatible event format might intentionally allow extra fields and should document that different decision.
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"item": { "type": "string", "minLength": 1 },
"seats": { "type": "integer", "minimum": 1, "maximum": 8 },
"note": { "type": ["string", "null"] }
},
"required": ["item", "seats"],
"additionalProperties": false
}Separate property presence from its value
Listing a property under properties describes how its value is checked when present; required names the properties that must exist. The object reference explains this division. In this example, omitting note is allowed, and supplying note as null is also allowed, because the schema deliberately permits both cases.
Omitting seats must fail. Supplying seats as null must also fail, but for a different reason: the property exists and its value is not an integer. Preserve that distinction when mapping validation errors into a form, because adding a missing value and replacing an invalid value are different corrective actions.
A minLength of one rejects an empty string but accepts a string containing a space. If a business rule requires nonblank text, define and test that rule separately. Do not assume that a familiar-looking keyword performs trimming or other normalization that the schema never requested.
Test the numeric boundary on both sides
For seats, zero and nine fail while one and eight pass. The value 1.5 fails the integer rule, and the string "2" fails the type rule. These fixtures help distinguish numeric range enforcement from accidental string coercion. See the numeric reference for the keyword semantics used by the selected dialect.
Decide where normalization belongs. A form control may initially provide a string, while the validated API request expects a number. Convert and validate that value deliberately in the application boundary, then submit the agreed JSON representation. Quietly enabling coercion in one validator but not another can make the browser and server disagree about the same request.
Keep external business checks outside this small schema
The example can check the structure of an item code, but it cannot establish that the item exists in the current catalog or that eight seats remain available. Those facts depend on application state. Validate the request shape and then perform the necessary authorized business operation with its own consistency controls.
Likewise, a structurally valid note is not automatically safe to render as HTML, and a valid item code does not grant permission to reserve it. Schema validation is one boundary in the request workflow. Keep authorization, output handling and transaction behavior explicit rather than attaching unsupported guarantees to a passing schema result.
Maintain fixtures with the schema
The JSON Schema Generator From JSON infers an initial draft from sample data. A sample containing two seats cannot reveal the intended maximum of eight or whether note is optional. Review and amend its output against the actual requirements before using it as a contract.
Keep valid and invalid examples beside the schema, including missing, null, empty, wrong-type, extra-property and boundary cases. Run them through the exact configured validator used by the service. When the contract changes, update the expected outcomes deliberately and check whether older clients still produce accepted requests.
Related guides
A practical guide to scala json schema, including the key steps and checks for schema draft, required fields, types and validation errors.
Step through ruby json schema and verify schema draft, required fields, types and validation errors before you use or share the result.
Separate JSON Schema validation from Schema.org JSON-LD, choose markup that matches visible content, and check search eligibility honestly.