JSON Schema-validatie: JSON valideren in Node, Python en de browser (2026)
JSON Schema is een contract voor JSON-data. Je legt veldtypen, verplichte sleutels en beperkingen vast, en een validator controleert of een JSON-document zich aan dat contract houdt. Gebruik Ajv in Node voor de snelste validatie, de jsonschema-bibliotheek in Python voor draagbare schema’s, en bundel Ajv in de browser voor directe feedback op formulieren en configuratie. Draft 2020-12 is de versie die je in 2026 voor nieuwe projecten kiest.
Hieronder staat het kleinste werkende voorbeeld, gevolgd door end-to-end-patronen in alle drie de runtimes en de valkuilen uit de praktijk die de bug “validatie slaagt maar productie weigert de data” veroorzaken.
Wat JSON Schema wel en niet is
Een definitie in één zin
Een JSON Schema is een JSON-document dat de vorm van andere JSON-documenten beschrijft. Een validator leest het schema en de data, en bevestigt dan dat ze overeenkomen of geeft de paden terug die falen.
Het kleinste bruikbare voorbeeld:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": { "name": { "type": "string" } },
"required": ["name"]
}{"name": "Alice"} slaagt. {"age": 30} faalt (name ontbreekt). {"name": 42} faalt (name is geen string). Dat is het hele mentale model.
JSON Schema versus JSON-syntaxisvalidatie
Twee verschillende problemen, vaak verward.
| Dimensie | JSON-syntaxiscontrole | JSON Schema-validatie |
|---|---|---|
| Wat het controleert | Is dit een geldig JSON-document? | Komt deze JSON overeen met het contract? |
| Wat het vangt | Ontbrekende komma’s, enkele aanhalingstekens, opmerkingen | Verkeerde typen, ontbrekende verplichte velden, waarden buiten bereik |
| Tools | JSON.parse(), JSON Formatter | Ajv, jsonschema (Python), fastjsonschema |
| Wanneer je het pakt | Eerste stap, vóór het parsen | Direct na het parsen, vóór de bedrijfslogica |
In de praktijk doe je beide: pretty-print de payload in JSON Formatter om te bevestigen dat hij parseert, en haal hem dan door een schema om te bevestigen dat hij aan het contract voldoet.
JSON Schema versus JSONPath, JSON Patch, jq en TypeScript
Vijf tools delen dit probleemveld. De beslismatrix:
| Tool | Vraag die het beantwoordt | Pak het wanneer |
|---|---|---|
| JSON Schema | Komt deze JSON overeen met de verwachte structuur? | API-input, configuratiebestanden, formulier-payloads valideren |
| JSONPath | Hoe haal ik een waarde uit deze JSON? | Geneste velden ophalen, batch reads |
| JSON Patch (RFC 6902) | Hoe beschrijf ik de diff van A naar B? | Samen bewerken, incrementele sync |
| jq | Hoe verwerk ik JSON op de command line? | Shellscripts, log-pipelines, CI-checks |
| TypeScript-types | Gebruikt mijn code deze vorm correct? | Compile-time-garanties binnen één codebase |
Het verschil dat alles bepaalt: JSON Schema valideert onbekende data tijdens runtime, TypeScript valideert bekende code tijdens compile time. TypeScript helpt niet bij JSON van een externe webhook of een door een gebruiker geplakt fragment; daar is JSON Schema voor bedoeld. Zod en Pydantic zitten ergens tussenin (compile-time-types plus runtime-validatie); die komen hieronder aan bod.
JSON Schema versus OpenAPI
Een veelgehoord misverstand is dat OpenAPI JSON Schema vervangt. Dat klopt niet. OpenAPI gebruikt JSON Schema intern om request- en response-bodies te beschrijven, en legt daar paden, parameters, beveiligingsschema’s en server-URL’s bovenop. Het schema is het contract voor de datavorm; OpenAPI is het API-contract dat eromheen zit.
| Dimensie | JSON Schema | OpenAPI |
|---|---|---|
| Bereik | Vorm van één JSON-document | Vorm van een hele HTTP API |
| Afhankelijkheden | Geen (schema is op zichzelf staande JSON) | Importeert JSON Schema voor body-definities |
| Versiekoppeling | Draft 7 / Draft 2019-09 / Draft 2020-12 | OpenAPI 3.0 gebruikt een Draft 4-subset; OpenAPI 3.1 gebruikt Draft 2020-12 native |
| Typisch gebruik | Configuratiebestanden, message-envelopes, formuliervalidatie, single-payload-contracten | REST API-ontwerp, SDK-generatie, mockservers, contract-tests |
| Codegeneratie | Beperkt (een paar quicktype-achtige tools) | Volwassen ecosysteem (openapi-generator, oapi-codegen, vendor-SDK’s) |
| Contractbeheer | Eén bestand per vorm, geen routing | Paden, operations, auth-flows en versies van endpoints in één document |
Pak gewoon JSON Schema wanneer het artefact dat je wilt vastleggen één enkel document is: een webhook-payload, een configuratiebestand, een queue-message of een formulier. Er is geen HTTP-oppervlak om te beschrijven, dus OpenAPI is overhead.
Pak OpenAPI wanneer je een HTTP API publiceert en één document wilt dat docs, SDK-generatie, mockservers en contract-tests aanstuurt. Definieer je schema’s eerst als zelfstandige JSON Schema-bestanden in een schemas/-map, en gebruik daarna $ref vanuit het OpenAPI-document. Zo blijven de schema’s herbruikbaar buiten de API-context.
De versiekoppeling brengt teams in verwarring. OpenAPI 3.0 gebruikt een Draft 4-subset, dus je kunt geen Draft 2020-12-keywords zoals prefixItems of unevaluatedProperties binnen een 3.0-document gebruiken; de generators negeren ze stilletjes. OpenAPI 3.1 is een superset van Draft 2020-12, dus alles wat geldig is in 2020-12 is geldig in 3.1. Heb je de keuze, mik dan op OpenAPI 3.1 en schrijf overal Draft 2020-12-schema’s.
Je eerste JSON Schema (5 minuten)
De keywords die je eerst nodig hebt
Met dit handvol kom je een heel eind:
{
"type": "object",
"properties": {
"id": { "type": "integer", "minimum": 1 },
"email": { "type": "string", "format": "email" },
"age": { "type": "integer", "minimum": 0, "maximum": 150 },
"tags": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
"role": { "enum": ["admin", "editor", "viewer"] },
"metadata": { "type": "object", "additionalProperties": true }
},
"required": ["id", "email"],
"additionalProperties": false
}Het vocabulaire:
type:string,number,integer,boolean,null,array,objectpropertiesplusrequireddeclareren welke velden er zijn en welke aanwezig moeten zijnenumofconstbeperken tot een vaste set of één enkele literalminimum,maximum,multipleOfzetten numerieke grenzenminLength,maxLength,patternregelen stringlengte en regexminItems,maxItems,uniqueItemsregelen de vorm van arraysadditionalProperties: falsewijst niet-gedeclareerde sleutels af; zet dit altijd aan op input-contracten
JSON Schema-voorbeelden per use case
Bovenstaande keywords komen in verschillende combinaties terug, afhankelijk van wat je valideert. Een paar representatieve vormen:
API request body — een signup-endpoint dat e-mail en wachtwoord accepteert:
{
"type": "object",
"properties": {
"email": { "type": "string", "format": "email" },
"password": { "type": "string", "minLength": 8, "maxLength": 128 }
},
"required": ["email", "password"],
"additionalProperties": false
}Configuratiebestand — een logger-config die het level vastpint op een vaste set:
{
"type": "object",
"properties": {
"level": { "enum": ["debug", "info", "warn", "error"] },
"output": { "type": "string", "default": "stdout" }
},
"required": ["level"],
"additionalProperties": false
}Formulier-payload met conditionele regels — wanneer accountType "business" is, wordt taxId verplicht:
{
"type": "object",
"properties": {
"accountType": { "enum": ["personal", "business"] },
"taxId": { "type": "string" }
},
"if": { "properties": { "accountType": { "const": "business" } } },
"then": { "required": ["taxId"] }
}CSV-rij als JSON-record — één rij van een geëxporteerde orders-tabel:
{
"type": "object",
"properties": {
"orderId": { "type": "string", "pattern": "^ORD-[0-9]{6}$" },
"orderedOn": { "type": "string", "format": "date" },
"totalUsd": { "type": "number", "minimum": 0 }
},
"required": ["orderId", "orderedOn", "totalUsd"]
}Webhook-event-envelope — oneOf discrimineert op de type-literal, zodat elke event-variant een eigen payload-vorm heeft:
{
"oneOf": [
{ "properties": { "type": { "const": "order.created" }, "data": { "$ref": "#/$defs/order" } } },
{ "properties": { "type": { "const": "order.refunded" }, "data": { "$ref": "#/$defs/refund" } } }
]
}Deze vijf voorbeelden dekken het gros van wat teams in de praktijk schrijven. Kopieer de variant die er het dichtst bij ligt en pas de veldnamen aan; het keyword-vocabulaire blijft hetzelfde.
Valideren zonder iets te installeren
Plak schema en payload in de playground op ajv.js.org of jsonschemavalidator.net voor een direct oordeel. Oogt de JSON zelf verdacht, haal hem dan eerst door JSON Formatter.
Valideren in Node.js met Ajv
Installeren en een voorbeeld van 12 regels
Ajv compileert je schema bij de eerste compile tot een geoptimaliseerde functie en hergebruikt die daarna.
npm install ajvimport Ajv from "ajv";
const ajv = new Ajv();
const schema = {
type: "object",
properties: {
name: { type: "string" },
age: { type: "integer", minimum: 0 }
},
required: ["name"]
};
const validate = ajv.compile(schema);
const data = { name: "Alice", age: 30 };
if (!validate(data)) console.log(validate.errors);
else console.log("OK");Overstappen naar Draft 2020-12
De standaard Ajv-constructor zit voor achterwaartse compatibiliteit nog op Draft 7. Kies expliciet voor 2020-12:
import Ajv2020 from "ajv/dist/2020";
const ajv = new Ajv2020({ strict: true, allErrors: true });Nu zijn prefixItems, unevaluatedProperties en $dynamicRef beschikbaar. Zie de Draft 2020-12-sectie hieronder voor wat elk doet.
format-validatie aanzetten
Over deze Ajv-eigenaardigheid struikelen meer ontwikkelaars dan over welke andere ook: format: "email" doet standaard niets. De spec behandelt format als adviserend, dus je moet de format-module zelf registreren:
npm install ajv-formatsimport addFormats from "ajv-formats";
addFormats(ajv); // nu valideert "format": "email" daadwerkelijkZonder deze stap slaagt {"email": "not-an-email"} voor een schema dat format: "email" vereist. Installeer ajv-formats altijd in productie.
Express-middleware in de praktijk
Eén validator per route, gecompileerd bij de boot:
import express from "express";
import Ajv2020 from "ajv/dist/2020";
import addFormats from "ajv-formats";
const ajv = new Ajv2020({ allErrors: true });
addFormats(ajv);
const validateUser = ajv.compile({
type: "object",
properties: {
email: { type: "string", format: "email" },
age: { type: "integer", minimum: 13 }
},
required: ["email"],
additionalProperties: false
});
const app = express();
app.use(express.json());
app.post("/users", (req, res) => {
if (!validateUser(req.body)) {
return res.status(400).json({ errors: validateUser.errors });
}
// ... bedrijfslogica
res.status(201).json({ ok: true });
});De duurste fout die je hier kunt maken is ajv.compile(schema) aanroepen binnen de request handler. Compileer één keer op module-niveau en hergebruik de teruggegeven functie. Wie per request hercompileert, ziet de doorvoer 50× of meer kelderen.
Valideren in Python met jsonschema
Installeren en basisgebruik
pip install jsonschemafrom jsonschema import validate, ValidationError
schema = {
"type": "object",
"properties": {
"name": {"type": "string"},
"age": {"type": "integer", "minimum": 0}
},
"required": ["name"]
}
try:
validate(instance={"name": "Alice", "age": 30}, schema=schema)
print("OK")
except ValidationError as e:
print("FAIL:", e.message, "at", list(e.absolute_path))Alle fouten verzamelen met Draft202012Validator
validate() gooit bij de eerste fout. Gebruik iter_errors om elk probleem in één keer op te sommen (handig voor formulierreacties):
from jsonschema import Draft202012Validator
validator = Draft202012Validator(schema)
errors = sorted(validator.iter_errors(instance), key=lambda e: e.path)
for err in errors:
print(f" - {'/'.join(map(str, err.absolute_path))}: {err.message}")Nu kan de gebruiker alles in één keer corrigeren, in plaats van veld voor veld door foutrondes te lopen.
jsonschema versus Pydantic: wanneer kies je wat
Twee sterke Python-bibliotheken, twee verschillende problemen.
| Dimensie | jsonschema | Pydantic v2 |
|---|---|---|
| Schema-formaat | Een JSON-dict (schema is data) | Een Python-klasse met type hints |
| Performance | Geïnterpreteerd, ~10–100× trager dan Pydantic | Rust-kern, de snelste in het ecosysteem |
| Cross-language draagbaarheid | Ja (hetzelfde schema werkt in JS, Go, Rust) | Nee (alleen Python) |
| FastAPI- / native model-integratie | Handmatige conversie | Ingebouwd |
Volledige Draft 2020-12-keywords ($dynamicRef, etc.) | Compleet | Gedeeltelijk |
De vuistregel die zich in productie bewijst: gebruik jsonschema voor cross-language-contracten (OpenAPI, publieke API’s, webhooks), en gebruik Pydantic voor interne Python-services. Veel teams draaien beide naast elkaar: jsonschema bij de gateway om het contract te handhaven, Pydantic op de applicatielaag voor getypeerde bedrijfslogica. Het schema is het draagbare artefact, identiek aan wat je aan Ajv zou voeren.
Valideren in de browser
Waarom überhaupt aan de clientzijde valideren
Drie redenen, van zwaarwegend naar nice-to-have:
- UX: directe feedback terwijl de gebruiker typt voelt sneller dan een server-rondje afwachten
- Bandbreedte: voor de hand liggende fouten verlaten de browser nooit
- Beveiligingshygiëne: minder ruis op de backend; geen vervanging voor server-validatie
Vertrouw nooit alleen op clientzijde-validatie. Valideer altijd opnieuw op de server.
Ajv bundelen voor de browser
npm install ajv ajv-formatsimport Ajv2020 from "ajv/dist/2020";
import addFormats from "ajv-formats";
const ajv = new Ajv2020({ allErrors: true });
addFormats(ajv);
export const validateForm = ajv.compile({
type: "object",
properties: {
email: { type: "string", format: "email" },
password: { type: "string", minLength: 8 }
},
required: ["email", "password"]
});De bundel komt op ongeveer 30 KB gzipped: merkbaar, maar geen ramp. Teams pakken Ajv vooral wanneer ze één schema-definitie willen delen tussen server en client.
Lichtere alternatieven: Zod en Valibot
Als je het JSON Schema-ecosysteem niet nodig hebt en al in TypeScript zit, geeft een TS-native validator je kleinere bundels en strakkere type-inferentie:
import { z } from "zod";
const UserSchema = z.object({
email: z.string().email(),
password: z.string().min(8)
});
const result = UserSchema.safeParse(data);
if (!result.success) console.log(result.error.issues);Valibot levert ongeveer 3 KB gzipped met een vergelijkbare API. Kies die wanneer bundelgrootte doorslaggevend is. De catch is dat geen van beide bibliotheken JSON Schema produceert. Heb je één bron van waarheid nodig die je deelt met backends, externe clients of OpenAPI-generatoren, blijf dan bij Ajv. Werk je puur in je eigen TypeScript-codebase, dan zijn Zod en Valibot ergonomischer.
Wat Draft 2020-12 toevoegt
prefixItems voor tuple-validatie
Draft 7 drukte tuples uit via items: [] plus additionalItems. Draft 2020-12 splitst ze schoon:
{
"type": "array",
"prefixItems": [
{ "type": "string" },
{ "type": "number" }
],
"items": false
}["x", 42] slaagt. ["x", 42, "extra"] faalt. Het schema leest precies zoals het werkt.
unevaluatedProperties voor samengestelde schema’s
Een subtiele bug waar vrijwel elk team tegenaan loopt zodra het allOf of oneOf gebruikt: additionalProperties: false controleert alleen het niveau waarop het zelf staat. Aangrenzende subschema’s binnen allOf declareren ondertussen hun eigen properties. De fix in 2020-12 is unevaluatedProperties: false:
{
"allOf": [
{ "$ref": "#/$defs/base" }
],
"unevaluatedProperties": false
}Dit wijst elke property af die door geen enkele tak is geëvalueerd. Precies het gedrag dat de meeste ontwikkelaars al van additionalProperties: false verwachtten.
$dynamicRef voor recursieve schema’s
Wie in Draft 7 ooit een recursief boomschema heeft proberen te declareren, kent de bochten die daarvoor nodig waren. $dynamicRef plus $dynamicAnchor ruimt dit op:
{
"$dynamicAnchor": "node",
"type": "object",
"properties": {
"value": { "type": "string" },
"children": { "type": "array", "items": { "$dynamicRef": "#node" } }
}
}De recursie is declaratief en kun je vanuit afstammelingen overschrijven zonder dat je $id hoeft te herschrijven.
Draft 7 versus 2020-12: welke kies je
- Nieuw project, moderne toolchain: Draft 2020-12
- OpenAPI 3.1 bouwen of consumeren: 2020-12 is het native dialect
- Werken met OpenAPI 3.0 of oudere services: Draft 4 (OpenAPI 3.0 gebruikt een Draft 4-subset; meng geen dialecten)
- Brede validator-compatibiliteit nodig (Postman, oudere CI-tools): Draft 7 is nog steeds het veiligste uitwisselingsformaat
Elke moderne validator ondersteunt 2020-12 inmiddels: Ajv, Python jsonschema, jsonschema-rs, Java’s networknt/json-schema-validator.
Praktijkpatronen
API-input-validatie
De Express-middleware hierboven is de productievorm. Twee aanvullende praktijken zijn nuttig: bewaar alle schema’s in een schemas/-map in de root van de repo, en voeg een CI-stap toe die ajv test (of het Python-equivalent) draait om de schema’s zelf tegen het JSON Schema-meta-schema te valideren.
Configuratiebestanden
Visual Studio Code komt met SchemaStore-integratie: autocomplete en inline validatie voor package.json, tsconfig.json en tientallen andere bestanden. Voeg een $schema-veld toe aan je eigen configs en gebruikers van de editor krijgen dezelfde behandeling.
CI-test-fixtures
Test-fixtures rotten weg. Iemand werkt een model bij, een fixture blijft op de oude vorm hangen, en de test slaagt nog steeds omdat de assertions het gewijzigde veld toevallig niet raken. Vang dit op met een schema-controle voordat de assertions draaien:
import { glob } from "glob";
const files = await glob("__tests__/fixtures/*.json");
for (const f of files) {
const data = JSON.parse(await fs.readFile(f, "utf8"));
if (!validate(data)) throw new Error(`${f}: ${ajv.errorsText(validate.errors)}`);
}Wanneer de schema-controle afgaat, is de volgende stap meestal een structurele diff. Trek de fixture in JSON vergelijken tegen een verse productie-sample om te zien waar het uit elkaar is gelopen. Als tijdstempels en ID’s de diff overheersen, pak dan de snapshot-padnegeerpatronen uit de JSON-diff-gids erbij om signaal van ruis te scheiden.
Webhook-payloads (Stripe, GitHub)
Webhooks van derden zijn een van de plekken waar JSON Schema het meeste oplevert. De webhook is een contract, de provider kan het wijzigen, en je wilt het moment kennen waarop dat gebeurt. Stripe en GitHub publiceren OpenAPI-beschrijvingen waaruit je JSON-schema’s kunt extraheren. Valideer inkomende events, dan licht een breekwijziging op in je monitoring in plaats van stilletjes je state te corrumperen.
Schema-gestuurde formuliervalidatie
React Hook Form heeft een @hookform/resolvers/ajv-adapter, en Vue’s VeeValidate kent een gelijkwaardige Ajv-plugin. Beide sturen formulier-rendering, foutmeldingen en submit-validatie aan vanuit één JSON Schema. Het schema is de enige bron van waarheid en de UI erft de regels ervan.
Vriendelijke foutmeldingen
Waarom de standaardmeldingen ruw zijn
Standaard produceert Ajv fouten als #/properties/email format must match "email". Prima voor een engineer die een 400 zit te debuggen, onbruikbaar voor iemand die een afrekenformulier probeert in te vullen.
ajv-errors voor aangepaste meldingen
npm install ajv-errorsimport ajvErrors from "ajv-errors";
ajvErrors(ajv);
const schema = {
type: "object",
properties: { email: { type: "string", format: "email" } },
required: ["email"],
errorMessage: {
properties: { email: "Vul een geldig e-mailadres in" },
required: { email: "E-mail is verplicht" }
}
};Het errorMessage-keyword blijft binnen het schema, dus validatieregels en de tekst die de eindgebruiker te zien krijgt reizen samen op.
ajv-i18n voor vertaalde fouten
ajv-i18n levert vertalingen van de standaardberichten in 30+ talen. Eén regel bij de start en je validator spreekt Spaans, Frans, Japans of welke locales je verder ook bedient. Handig als terugval wanneer je errorMessage-overschrijvingen niet elke beperking dekken.
Schema-paden koppelen aan formuliervelden
Elke Ajv-fout heeft een instancePath zoals /users/0/email. De meeste formulierbibliotheken verwachten gestippelde paden in de stijl users[0].email. One-liner:
const fieldPath = error.instancePath.replace(/^\//, "").replace(/\//g, ".");In Python’s jsonschema zit het equivalent op error.absolute_path. Plak die met een . aan elkaar voor hetzelfde effect.
Vijf valkuilen die door de validatie komen en dan in productie crashen
1. format is standaard adviserend
Zonder ajv-formats plus addFormats(ajv) is elk format-keyword een no-op. {"format": "email"} accepteert "not-an-email". Installeer in productie altijd het format-pakket.
2. additionalProperties staat standaard op true
Zonder additionalProperties: false accepteert je schema elk niet-gedeclareerd veld. Clients kunnen extra velden meesturen die de validatie volledig omzeilen. Maak additionalProperties: false standaard op input-contracten; versoepel bewust waar nodig.
3. additionalProperties componeert niet
Binnen allOf, oneOf of anyOf inspecteert additionalProperties: false alleen properties op zijn eigen niveau. Aangrenzende subschema’s glippen erdoor. De fix in Draft 2020-12 is unevaluatedProperties: false.
4. Remote $ref is een productierisico
$ref: "https://example.com/schema.json" laat Ajv bij de eerste compile over het netwerk fetchen. Dat betekent latentie, DoS-blootstelling als de remote host hapert en een MITM-aanvalsoppervlak. Inline alle $ref-doelen, of laad ze tijdens de build vanaf disk.
5. Gegenereerde schema’s wijken af van echte data
Tools als quicktype en typescript-json-schema genereren schema’s vanuit bestaande types. De output staat meestal te veel toe: elk veld optioneel, additionalProperties open. Behandel gegenereerde schema’s als concepten, scherp ze met de hand aan, en laat CI echte productie-samples tegen het schema valideren (en andersom) zodat afwijking snel aan het licht komt.
Performance: cijfers en vuistregels
- Ajv in Node.js: gecompileerde validators ronden één controle ruim onder een microseconde af. De snelste productiewaardige JS-validator die er is.
jsonschemain Python: geïnterpreteerd, 10–100× trager dan Pydantic. Wissel naarfastjsonschemawanneer dit knelt; die genereert Python-code en komt dicht bij Ajv.- Rust en Go:
jsonschema-rsenxeipuuv/gojsonschemaleveren nog eens 2–5× bovenop Ajv op de gateway-laag. - De grootste enkele winst zit in vooraf compileren. Roep
ajv.compile(schema)één keer aan bij module-load en hergebruik de teruggegeven validator bij elk request. Per request hercompileren doodt de doorvoer 50× of meer.
Veelgestelde vragen
Wat is JSON Schema-validatie in gewone taal?
JSON Schema-validatie controleert of een JSON-document een contract volgt. Het contract (het schema) is zelf JSON en declareert types, verplichte velden en beperkingen. Een validator leest het schema en de data en rapporteert “geslaagd”, of de paden die faalden en waarom.
Hoe valideer ik JSON online tegen een schema?
Plak schema en data in de ajv.js.org-playground of jsonschemavalidator.net voor een direct oordeel. Oogt de JSON misvormd, ruim hem dan eerst op in JSON Formatter. Beide draaien in de browser; er gaat niets de upload op.
Welke JSON Schema-validator is in 2026 het snelst?
In Node ronden vooraf gecompileerde Ajv-validators één controle af in minder dan een microseconde. In Python genereert fastjsonschema code en haalt zo Ajv-klasse-doorvoer. Op de gateway-laag zijn jsonschema-rs (Rust) en gojsonschema (Go) 2–5× sneller dan Ajv. Welke je ook kiest, compileer één keer vooraf en hergebruik dat resultaat.
Wat is het verschil tussen JSON Schema en TypeScript-types?
TypeScript controleert de code die jij schrijft, tijdens compile time. JSON Schema controleert onbekende JSON, tijdens runtime. TypeScript ziet geen JSON die binnenkomt vanuit een HTTP-respons, een bestand of een door een gebruiker geplakt fragment. Voor dat verkeer is JSON Schema bedoeld.
Moet ik Draft 2020-12 of Draft 7 gebruiken?
Voor nieuwe projecten in 2026 kies je Draft 2020-12. prefixItems, unevaluatedProperties en $dynamicRef lossen reële problemen op, en OpenAPI 3.1 gebruikt 2020-12 native. Blijf alleen op Draft 7 als je Postman-compatibiliteit of oudere services moet bedienen. OpenAPI 3.0 gebruikt een Draft 4-subset; meng geen dialecten.
Hoe genereer ik een JSON Schema vanuit bestaande JSON?
Een paar opties. Plak samples in quicktype.io of jsonschema.net, draai npx genson-js of pip install genson && genson sample.json op de command line, of schrijf het schema gewoon zelf. Automatisch gegenereerde schema’s zijn te ruim (elk veld optioneel, additionalProperties: true), dus scherp ze altijd aan voordat je ze als contracten behandelt.
Kan JSON Schema OpenAPI vervangen?
Nee. OpenAPI gebruikt JSON Schema intern om request- en response-bodies te beschrijven, en voegt daar bovenop paden, beveiligingsschema’s, parameters en server-URL’s aan toe. Ze stapelen op elkaar: schrijf je schema’s, verwijs er vanuit een OpenAPI-document naar, en je hebt volledige API-contracten.
Is JSON Schema hetzelfde als JSONPath of jq?
Nee, ze pakken verschillende problemen aan. JSON Schema valideert structuur (“komt deze JSON overeen met het contract?”). JSONPath en jq halen waarden op (“elke pod-naam in de Running-fase”). Valideer met een schema, query met JSONPath of jq.
Waarom slaagt mijn Ajv-validatie maar weigert productie de data?
Drie boosdoeners dekken bijna elk geval. Eén: ajv-formats vergeten, waardoor format: "email" nooit echt valideerde. Twee: additionalProperties: false weglaten, waardoor extra clientvelden er ongezien doorheen glippen. Drie: additionalProperties: false gebruiken binnen allOf of oneOf en ontdekken dat het niet componeert. Schakel in dat laatste geval over op unevaluatedProperties: false.
Kan ik JSON Schema-foutmeldingen aanpassen voor eindgebruikers?
Ja. Installeer in Node ajv-errors om errorMessage direct in het schema in te bedden, en ajv-i18n voor vertalingen in 30+ locales. In Python toont jsonschema de volledige validatiecontext op elk foutobject, dus je kunt fouttype plus pad mappen op welke tekst je designsysteem ook hanteert.