JSON Schema

Enforces strict data typing at the field level. JSON Schema defines seven primitive types: string, number, integer, object, array, boolean, and null. Each type has its own set of validation keywords.

• String constraints: minLength, maxLength, pattern (regex), and format (e.g., date-time, email, uri)
• Numeric constraints: minimum, maximum, exclusiveMinimum, multipleOf
• Array constraints: minItems, maxItems, uniqueItems, and contains for schema-based item matching
• Object constraints: minProperties, maxProperties, required, and additionalProperties

Combines schemas into complex validation logic using boolean algebra keywords. This enables modular schema design and reuse without duplicating definitions.

• allOf: The instance must validate against all of the given schemas (logical AND). Used for schema inheritance and mixins.
• anyOf: The instance must validate against at least one of the given schemas (logical OR). Useful for polymorphic data.
• oneOf: The instance must validate against exactly one of the given schemas (exclusive OR). Critical for disambiguation in tagged unions.
• not: The instance must not validate against the given schema (logical NOT).

Applies subschemas based on the value of another field, enabling dynamic validation logic that adapts to the data instance.

• if/then/else: If the instance validates against the if schema, it must also validate against the then schema; otherwise, it must validate against the else schema.
• dependentRequired: Specifies that if a certain property is present, other properties become required.
• dependentSchemas: Applies an entire subschema conditionally based on the presence of a property.

Example: If "country": "US", then the zipCode field must match a 5-digit pattern.

Enables modular schema authoring by defining reusable components in a central $defs block and referencing them via the $ref keyword using JSON Pointer syntax.

• $defs: A keyword for defining named subschemas within a single document.
• $ref: A URI reference that points to a subschema, either locally (#/$defs/address) or externally (https://example.com/schemas/address.json).
• Recursive schemas: A schema can reference itself via $ref to validate recursive data structures like trees or nested comments.
• $dynamicRef: Resolves references based on the runtime scope, enabling true polymorphic schema resolution.

Provides human-readable metadata that does not affect validation but enriches the schema for documentation, UI generation, and code generation.

• title: A short, human-readable name for the schema or property.
• description: A detailed explanation of the purpose and constraints of a field.
• default: A default value for the property, used by documentation and code generators.
• examples: An array of sample valid values to illustrate expected data.
• deprecated: A boolean flag indicating that a property should no longer be used.
• readOnly and writeOnly: Indicate whether a property is for output or input only, critical for API design.

The format keyword provides semantic validation for common string patterns. While the base specification defines format as an annotation, most validators treat it as an assertion.

• date-time: RFC 3339 timestamps (e.g., 2024-01-15T14:30:00Z)
• email: RFC 5322 email addresses
• uri: RFC 3986 URIs
• ipv4 and ipv6: IP address validation
• uuid: Universally unique identifiers
• hostname: RFC 1123 hostnames
• json-pointer: RFC 6901 JSON Pointers

Custom format validators can be registered in most implementations for domain-specific patterns.

The process of modifying a JSON Schema over time while maintaining compatibility with existing data and consumers. Key strategies include:

• Backward Compatibility: New schemas can read old data (add optional fields only)
• Forward Compatibility: Old schemas can read new data (use additionalProperties: true cautiously)
• Full Compatibility: Both directions work simultaneously Schema evolution is critical for distributed systems where producers and consumers upgrade independently. JSON Schema supports this through versioned $id URIs and the $schema keyword to declare which draft is in use.

A centralized repository for storing, versioning, and governing JSON Schemas across an organization. Popular implementations like Confluent Schema Registry (for Avro/Protobuf/JSON Schema) or Apicurio Registry provide:

• Schema storage with unique IDs and version history
• Compatibility checking to prevent breaking changes
• Serialization/deserialization libraries that fetch schemas automatically In event-driven architectures, a registry ensures that every Kafka topic or message queue has a well-defined, discoverable contract.

A lightweight Linked Data format that uses JSON syntax to serialize structured data with semantic context. Unlike JSON Schema which validates structure, JSON-LD adds meaning by mapping JSON keys to globally unique IRIs (Internationalized Resource Identifiers). Key features:

• @context keyword maps terms to RDF vocabularies like Schema.org
• @type declares the class of an entity (e.g., Person, Product)
• Enables semantic search and knowledge graph integration JSON-LD and JSON Schema are complementary: Schema validates the shape, JSON-LD provides the semantics.