Podcast on JSON: Data Interchange and Schema

Kapitoly

JSON

Přepis

Mia: Tady je ten nejčastější chyták, na který narazí 80 % studentů u zkoušky z JSONu. Vidíte poslední položku v seznamu a instinktivně za ni napíšete čárku. A bum... celý soubor je neplatný. Dnes vám ukážeme, proč se to děje a jak se této a dalším běžným chybám navždy vyvarovat.

Mia: Jste u Studyfi Podcast.

Mia: Tak jo, Same, pojďme na to. Co je to za magii jménem JSON, která pohání tolik aplikací, a proč jediná čárka navíc může všechno zničit?

Sam: To je skvělá otázka, Mio. Není to magie, i když to tak někdy vypadá. Představte si JSON jako univerzální jazyk pro data. Je to způsob, jak strukturovat informace tak, aby jim počítače snadno rozuměly, bez ohledu na to, v jakém programovacím jazyce jsou napsané.

Mia: Takže je to takový digitální esperanto?

Sam: Přesně! Je to textový formát, který je lehký a pro lidi snadno čitelný. Jeho celý název je JavaScript Object Notation, protože jeho syntaxe vychází ze způsobu, jak se v JavaScriptu zapisují objekty. Ale nenechte se zmást, používá se úplně všude.

Mia: Dobře, a co to znamená v praxi? Kde se s ním setkám?

Sam: Téměř všude, kde aplikace komunikují přes internet. Když vaše mobilní aplikace načítá data ze serveru, třeba předpověď počasí nebo nové příspěvky na sociální síti, je velmi pravděpodobné, že si je posílají právě ve formátu JSON.

Mia: Takže to je ten proces, kterému se říká serializace a deserializace?

Sam: Přesně tak. Serializace je proces, kdy vezmete data z programu, třeba objekt s informacemi o uživateli, a převedete je na textový řetězec JSON, abyste je mohli poslat po síti. Deserializace je opačný proces – vezmete ten řetězec JSON a v cílové aplikaci ho zase převedete zpět na datový objekt, se kterým může program pracovat.

Mia: Zní to jako balení a rozbalování balíku, než ho pošlete poštou.

Sam: To je perfektní přirovnání! A stejně jako pošta má svá pravidla pro balení, i JSON má svá přísná pravidla syntaxe. A proto ta čárka navíc způsobí, že pošťák, tedy program, ten balík odmítne doručit.

Mia: Rozumím. Takže je standardizovaný?

Sam: Ano, a ten standard je až neuvěřitelně jednoduchý. Jmenuje se ECMA-404 a celý dokument má jen pár stránek. Definuje přesně, co je a co není platný JSON. Žádné výjimky.

Mia: Fascinující. Používá se tedy hlavně pro komunikaci mezi klientem a serverem? Nebo i jinde?

Sam: To je jeho hlavní role, ale najdete ho i v konfiguračních souborech různých nástrojů nebo dokonce jako formát pro ukládání dat v některých NoSQL databázích. Je opravdu všestranný.

Mia: Dobře, tak se pojďme podívat na ta přísná pravidla balení. Jaké jsou základní stavební kameny JSONu?

Sam: Jsou v podstatě jen dva hlavní. Objekty a pole. A pak samozřejmě hodnoty, které do nich vkládáte.

Mia: Objekty a pole. To zní povědomě z programování.

Sam: Přesně tak. Objekt v JSONu je sada párů klíč-hodnota, uzavřená ve složených závorkách {}. Klíč je vždy textový řetězec v uvozovkách a za ním následuje dvojtečka a pak hodnota. Například "jmeno": "Franta".

Mia: A co je důležité si pamatovat u klíčů?

Sam: Klíče, tedy ty názvy vlastností, musí být vždy v dvojitých uvozovkách. Vždy. To je častá chyba, na kterou si dát pozor. Jednoduché uvozovky nebo žádné uvozovky nejsou povolené.

Mia: Rozumím, takže {"jmeno": "Franta"} je správně, ale {jmeno: "Franta"} by neprošlo.

Sam: Přesně. A druhým stavebním kamenem je pole, anglicky array. To je prostě uspořádaný seznam hodnot, uzavřený v hranatých závorkách . Jednotlivé hodnoty v seznamu jsou oddělené čárkami.

Mia: Takže třeba nebo ?

Sam: Ano. A teď to nejdůležitější – co může být tou hodnotou? Tady je JSON velmi konkrétní.

Mia: Povídej.

Sam: Hodnotou může být řetězec, což je text v dvojitých uvozovkách. Dále číslo, ať už celé nebo desetinné. Pak logické hodnoty true a false. Speciální hodnota null, která znamená 'nic'. A teď to nejlepší... hodnotou může být i další objekt nebo další pole.

Mia: Aha! Takže tak se vytváří ta vnořená struktura, kterou často vídáme?

Sam: Přesně tak! Můžete mít objekt, jehož jednou z hodnot je pole, a v tom poli můžou být další objekty. Tímto způsobem můžete strukturovat i velmi složitá data.

Mia: A teď k té zpropadené čárce...

Sam: Ano, ta čárka. Pravidlo je jednoduché: čárky se používají k oddělení prvků v poli nebo párů klíč-hodnota v objektu. Ale za posledním prvkem v jakémkoli seznamu se čárka nikdy nesmí objevit. To je nekompromisní pravidlo.

Mia: Takže { "jmeno": "Franta", "vek": 25 } je správně, ale { "jmeno": "Franta", "vek": 25, } je chyba.

Sam: Přesně. To je ten detail, který nachytá 80 % lidí. Zapamatujte si: žádná koncová čárka. Nikdy.

Mia: Dobře, takže teď víme, jak JSON vypadá a jaká má pravidla. Ale co když chci zajistit, aby data, která dostanu, měla vždy správnou strukturu? Třeba že objekt 'uživatel' musí vždy obsahovat email a jméno?

Sam: Skvělá otázka, Mio. Tady přichází na řadu JSON Schema. Představte si to jako blueprint nebo šablonu pro vaše JSON data.

Mia: Takže je to vlastně soubor pravidel, který říká, jak má platný JSON pro můj konkrétní případ vypadat?

Sam: Přesně. JSON Schema je samo o sobě taky platný JSON dokument! V něm definujete, jaké vlastnosti má objekt mít, jakého datového typu mají být jejich hodnoty, které vlastnosti jsou povinné a které volitelné a mnoho dalšího.

Mia: To zní neuvěřitelně užitečně. Takže si můžu ověřit, jestli data, která mi poslala nějaká API, odpovídají tomu, co očekávám?

Sam: Přesně k tomu to slouží. Říká se tomu validace. Nejdřív ověříte, jestli je dokument syntakticky správný JSON, a pak ho validujete proti schématu, abyste zjistili, jestli má správnou strukturu a obsah.

Mia: Jak se takové schéma píše?

Sam: Začíná to deklarací, kde říkáte, jakou verzi specifikace JSON Schema používáte. Pak obvykle přidáte název a popis. A nejdůležitější je klíč "type", kde definujete, jestli je kořenový prvek objekt nebo pole.

Mia: A pak definuju jednotlivé vlastnosti?

Sam: Ano, u objektu použijete klíč "properties". Uvnitř něj pro každou vlastnost definujete její typ, například "type": "string" nebo "type": "integer". Pomocí klíče "required" pak určíte seznam povinných vlastností.

Mia: Takže můžu říct, že productId musí existovat a musí to být celé číslo?

Sam: Přesně tak. A co víc, můžete přidat další omezení. U čísel třeba minimální a maximální hodnotu. U řetězců minimální a maximální délku nebo dokonce regulární výraz, kterému musí odpovídat.

Mia: To je síla. A co pole?

Sam: U polí můžete definovat, jakého typu mají být jeho položky pomocí klíče "items". Můžete nastavit minimální a maximální počet položek nebo jestli musí být všechny položky unikátní. Můžete dokonce definovat přesnou strukturu, kde první položka je číslo, druhá řetězec atd. Tomu se říká validace n-tice (tuple validation).

Mia: A co když mám složitější logiku? Třeba 'buď zadej tohle, nebo tamto'?

Sam: Na to má JSON Schema taky nástroje. Můžete kombinovat schémata pomocí klíčů jako allOf (musí splňovat všechna podschémata), anyOf (musí splňovat alespoň jedno) nebo oneOf (musí splňovat právě jedno). To vám dává obrovskou flexibilitu.

Mia: A co znovupoužitelnost? Nemusím přece definovat adresu uživatele na deseti různých místech, že ne?

Sam: Samozřejmě, že ne. Na to slouží klíč $ref. Můžete si vytvořit definici, třeba pro adresu, a pak se na ni na různých místech ve schématu jen odkazovat. To udržuje schémata čistá a snadno spravovatelná.

Mia: To je skvělé. Takže mám teď obrovský JSON soubor a vím, že je validní. Ale jak se dostanu k jedné konkrétní informaci, která je zanořená hluboko uvnitř?

Sam: Výborný přechod. Na to máme nástroje pro adresaci. Ten nejzákladnější se jmenuje JSON Pointer.

Mia: JSON Pointer? Co to je?

Sam: Představte si ho jako cestu k souboru ve vašem počítači. Je to řetězec, který začíná lomítkem a popisuje cestu od kořene dokumentu k požadované hodnotě. Každý krok cesty je oddělený lomítkem.

Mia: Můžeš dát příklad?

Sam: Jasně. Mějme objekt { "foo": }. Pokud chci hodnotu klíče "foo", JSON Pointer bude "/foo". To mi vrátí celé pole .

Mia: A když chci jen ten první prvek v poli?

Sam: Protože pole se indexují od nuly, cesta bude "/foo/0". To vám vrátí hodnotu "bar".

Mia: Jednoduché a efektivní. Je to ale dostatečně silné pro složitější dotazy?

Sam: Pro přímé adresování ano. Ale pokud potřebujete něco jako 'najdi všechny knihy, které stojí méně než 10 dolarů', potřebujete něco silnějšího. A tím je JSONPath.

Mia: JSONPath. To zní jako XPath pro XML, je to tak?

Sam: Přesně! Je to dotazovací jazyk pro JSON. Standardizace stále probíhá, ale už je široce používaný. Umožňuje vám prohledávat a filtrovat JSON data mnohem sofistikovaněji.

Mia: Jak to funguje?

Sam: Začínáte znakem dolaru $ , který reprezentuje kořenový dokument. Pak se můžete pohybovat pomocí tečkové notace, jako $.store.book.title, nebo pomocí notace s hranatými závorkami, .

Mia: A co to filtrování?

Sam: To je ta nejlepší část. Můžete použít speciální operátor otazníku v závorce . Takže dotaz 'všechny knihy s cenou pod 10' by vypadal nějak takto: $..book. Ten zavináč @ reprezentuje aktuální prvek, který se právě filtruje.

Mia: Wow, to už je o dost mocnější než JSON Pointer.

Sam: Rozhodně. JSON Pointer je na adresování, JSONPath je na dotazování.

Mia: Dobře, data umíme strukturovat, validovat a prohledávat. Co když je chci transformovat? Převést jednu JSON strukturu na jinou? Existuje něco jako XSLT pro JSON?

Sam: To je oblast, která není tak rozvinutá jako u XML, ale nástroje existují. Máme například JSLT, což je jazyk pro dotazování a transformaci, nebo JMESPath a JSONiq, které jsou spíše dotazovací. Ale je zajímavé, že i moderní XSLT verze 3.1 umí pracovat s JSONem. Může ho načíst a mapovat na datové struktury XPathu.

Mia: Takže i starý dobrý XSLT drží krok.

Sam: Přesně tak. Svět dat je propojený.

Mia: A když už jsme u propojování, existuje v JSONu něco jako jmenné prostory, abychom předešli kolizím názvů?

Sam: To je zajímavá otázka. Existoval nějaký návrh, ale nikdy se neujal. Místo toho se pro sémantické propojení dat používá něco, čemu se říká JSON-LD, neboli JSON for Linked Data.

Mia: Propojená data? Co si pod tím mám představit?

Sam: Je to způsob, jak do JSONu přidat kontext. Pomocí speciálních klíčů jako @context a @id můžete svá data propojit s existujícími slovníky na webu, jako je třeba Schema.org. To dává datům sémantický význam, který mohou stroje pochopit.

Mia: Takže místo "jmeno": "John Lennon" můžu říct, že tento konkrétní John Lennon je ta samá entita jako John Lennon v databázi DBpedia?

Sam: Přesně. Umožňuje to vytvářet sítě propojených dat napříč webem. Často to vidíte ve zdrojovém kódu stránek ve značce <script> pro účely SEO.

Mia: Fascinující. A na závěr, slyšela jsem o BSON. Je to nějaký příbuzný JSONu?

Sam: Je to jeho binární bratranec. BSON znamená Binary JSON. Je to binárně kódovaná serializace dokumentů podobných JSONu. Jeho výhodou je, že je efektivnější na zpracování a ukládání a podporuje další datové typy, které v JSONu nejsou, třeba datum nebo binární data. Používá ho například databáze MongoDB.

Mia: Takže je rychlejší, ale není čitelný pro lidi?

Sam: Přesně tak. Je to kompromis. Vyměníte lidskou čitelnost za rychlost a efektivitu stroje.

Mia: Perfektní. To byla vyčerpávající cesta světem JSONu. Pojďme si to rychle shrnout.

Sam: Jasně. Klíčový poznatek je, že JSON je textový formát pro výměnu dat, postavený na dvou strukturách: objektech a polích. Jeho syntaxe je extrémně přísná – pamatujte na dvojité uvozovky všude a žádné koncové čárky!

Mia: Abychom zajistili správnou strukturu dat, používáme JSON Schema, což je takový blueprint, proti kterému data validujeme. Je to neuvěřitelně mocný nástroj pro zajištění kvality dat.

Sam: Pro navigaci v datech máme JSON Pointer pro přímé adresování a JSONPath pro složitější dotazování a filtrování. A pak existují další technologie jako JSON-LD pro přidání sémantického významu a BSON jako efektivní binární alternativa.

Mia: Skvělé. Takže až příště u zkoušky uvidíte JSON, vzpomenete si na tu zrádnou koncovou čárku a s úsměvem se jí vyhnete.

Sam: Přesně tak. Máte to v kapse.

Mia: Díky moc, Same. Bylo to super poučné.

Sam: Rádo se stalo, Mio.

Mia: A vám děkujeme za poslech. Uslyšíme se zase příště u Studyfi Podcast.