JSON Schema: od základů k produkci
Klíčových slov je mnoho, ale denně se používá jen tucet. Zvládněte `type`/`properties`/`required`/`$ref`, dobře ošetřete chybové zprávy a pokryjete osmdesát procent skutečných případů.
Popište tvar vašich dat pomocí JSON Schema, změňte verbální dohody v vykonatelnou validaci a nechte ho postupně řídit typy TypeScript i generování formulářů.
7 článkůKlíčových slov je mnoho, ale denně se používá jen tucet. Zvládněte `type`/`properties`/`required`/`$ref`, dobře ošetřete chybové zprávy a pokryjete osmdesát procent skutečných případů.
Typy a schémata každé pokrývá jeden segment: jedno při kompilaci, druhé za běhu. Otázka není, které zvolit, ale jak udržet obě kopie automaticky v souladu.
Vygenerovaná schémata často blokují platná data. Zjistěte, proč bohatší vzorky dávají horší schémata, a poté pracovní postup: vzorkování více záznamů, doplnění sémantiky, přesné určení chyb.
$ref řeší znovupoužití, allOf a oneOf řeší kompozici, a právě jejich kombinování je místo, kde se věci rozbíjejí. Pokrývá $id, $defs, podmínky, rekurzi, bundling a ladění.
Validátor vydává strojové chyby; uživatel chce vědět, které vstupní pole je špatné. Pokrývá pole errors v Ajv, instancePath versus schemaPath, seskupování a formulaci.
Úspěšná validace neznamená čistá data. Pydantic standardně ignoruje neznámá pole, Zod je odstraní, Ajv je pustí — vymyšlené parametry a překlepy projdou potichu. Článek ukazuje tři formy tiché acceptance a dává kompletní recepty: zavřít objekty, zkontrolovat koerci, dotáhnout každou úroveň zanoření.
Schéma nekončí napsáním — tam začíná úpadek. Jedno překlepnutí potichu uvolní validaci, jeden refaktoring rozbije všechny fixture. Tato příručka rozebírá použitelné uspořádání kontraktního testování: pozitivní, negativní a snapshot fixture, lint samotného schématu, jednorázovou kompilaci s opakovaným použitím a čtyři brány CI, které promění porušení kontraktu v červený build.