JSON, XML és strukturált adatok

Célok

A lecke végére el tudod olvasni és meg tudod írni egy egyszerű JSON-t, ismered a JSON adattípusait és tipikus hibáit, tudod, mikor jöhet szóba az XML, és érted, miért nem pótolja az adatformátum az API-szerződést.

Miért kell közös adatformátum?

Az API-válasz nem attól hasznos, hogy szöveget tartalmaz, hanem attól, hogy a kliens következetesen értelmezni tudja. Ha a szerver szabadszövegben írná le a kurzust („A Webprogramozás kurzusra még kilenc hely van”), a kliensnek szövegelemzéssel kellene kinyernie az adatot, ami törékeny. Ezért az adatot strukturált formában küldjük: nevesített mezőkkel, típusokkal, listákkal. A két legelterjedtebb webes forma a JSON és az XML.

JSON

A JSON (JavaScript Object Notation) az RFC 8259 szerint „könnyű, szöveges, nyelvfüggetlen adatcsere-formátum”. A JavaScript objektumleíró szintaxisából származik, de bármely programozási nyelv kezeli. Hat adattípusa van: négy egyszerű (szöveg, szám, logikai érték, null) és két összetett (objektum, tömb).

{
  "id": "webprog",
  "cim": "Webprogramozás 1.",
  "ferohely": 40,
  "jelentkezett": 31,
  "elerheto": true,
  "oktato": null,
  "temak": ["HTTP", "böngésző", "API"]
}

• Az objektum ({ ... }) kulcs–érték párokból áll; a kulcsok szövegek, idézőjelek között.
• A tömb ([ ... ]) értékek rendezett listája.
• A logikai és null értékek kisbetűsek (true, false, null), az RFC szerint is.
• A hálózaton átküldött JSON kódolása UTF-8, a médiatípus pedig application/json (2.5).

A kulcsok a példában szándékosan ékezet nélküliek (cim, ferohely): a JSON megengedi az ékezetes kulcsot is, de az azonosítók ASCII (American Standard Code for Information Interchange) karakterekre korlátozása gyakori megegyezés, mert kevesebb kódolási és kezelési hibát okoz.

Futtatva: mit csinál a program a JSON-nal?

A fenti szöveget Node.js-sel beolvasva (JSON.parse):

const k = JSON.parse(szoveg);
console.log(typeof k.id, typeof k.ferohely, typeof k.elerheto, Array.isArray(k.temak), k.oktato, k.nincs_ilyen);
console.log("oktato in k:", "oktato" in k, "| nincs_ilyen in k:", "nincs_ilyen" in k);
console.log(k.ferohely - k.jelentkezett);

string number boolean true null undefined
oktato in k: true | nincs_ilyen in k: false
9

A számok számok maradnak, a null értékű mező létezik (az oktató még nincs kijelölve), a hiányzó mező viszont nincs a JSON-ban. A két eset nem azonos: a szerződésnek ki kell mondania, melyiket használja a szolgáltatás. A szabad helyek száma (ferohely - jelentkezett) 9.

Tipikus hibák

Az érvénytelen JSON nem olvasható be. Kipróbált példák:

{'cim': 'x'}        -> SyntaxError   (aposztróf idézőjel helyett)
{"cim": "x",}       -> SyntaxError   (záró vessző)
{"cim": "x"         -> SyntaxError   (hiányzó záró kapcsos zárójel)
{"ferohely": 040}   -> SyntaxError   (vezető nulla a számban)

Típushiba is lehet. Ha az API-szerződés szerint a ferohely szám, de szövegként érkezik ("40"), a kliens kódja észrevétlenül rosszul számol:

const x = JSON.parse('{"ferohely":"40"}');
console.log(x.ferohely + 1, typeof x.ferohely);   // 401 string

Az összeadás helyett összefűzés történt. A JSON maga nem véd az ilyen hibák ellen; a szerződésnek és az ellenőrzésnek kell.

Végül: a JSON nem ismer dátumtípust. A JavaScript JSON.stringify a dátumot szöveggé alakítja ("2026-10-11T12:00:00.000Z"), a undefined értékű mezőt pedig kihagyja. A dátum formátumáról tehát a szerződésben kell megállapodni.

XML

Az XML (Extensible Markup Language) a W3C ajánlása (XML 1.0, ötödik kiadás, 2008): általános célú jelölőnyelv, amelyet arra terveztek, hogy tartalmat lehessen vele a weben továbbítani és feldolgozni. Ugyanaz a kurzus XML-ben:

<kurzus id="webprog" elerheto="true">
  <cim>Webprogramozás 1.</cim>
  <temak><tema>HTTP</tema><tema>böngésző</tema><tema>API</tema></temak>
</kurzus>

Az XML elemekből és attribútumokból áll, amelyek egymásba ágyazhatók. Itt az elerheto attribútum értéke szöveg: hogy ez logikai érték, azt az adatséma vagy a dokumentáció mondja meg, maga a formátum nem. (Az XML-példát nem futtattuk, mert a Node.js alapkönyvtára nem tartalmaz XML-értelmezőt.)

Az XML nem „régi JSON”, hanem más modell, más eszközkészlettel. Olyan helyzetekben jön szóba, ahol dokumentumszerű szerkezet, névterek vagy már meglévő XML-alapú rendszerekkel való együttműködés kell.

flowchart LR
    A[Kurzus jelentése] --> J[JSON-szerkezet]
    A --> X[XML-szerkezet]
    J --> K[Kliens értelmezi]
    X --> K

Adat és dokumentum

A JSON tipikusan adatrekordokat, listákat és kapcsolatokat ír le, amelyeket a kliens feldolgoz. A HTML ezzel szemben webes dokumentum: a szerkezeten kívül a megjelenítéshez szükséges jelentést és hivatkozásokat is hordoz. Az XML mind adatcserére, mind dokumentumszerű tartalomra használható. A kategóriák nem kizárólagosak, de a felhasználási cél segít a formátum kiválasztásában.

Hiányzó adat és változó szerkezet

A formátum önmagában nem mondja meg, egy mező kötelező-e. Ha a kurzus oktatója még nincs kijelölve, a szerződésnek tisztáznia kell, hogy a mező hiányzik, null értékű, vagy más jelzést kap. A kliens nem következtethet az összes lehetséges állapotra egyetlen sikeres mintaválaszból. Ugyanígy a lista sorrendjéről, a dátumok alakjáról és az azonosítók jelentéséről is meg kell állapodni. A formátumválasztás tehát csak az első réteg; a valódi adatcsere szerződéses jelentésen alapul.

Az RFC 8259 arra is figyelmeztet, hogy az objektumon belüli kulcsnevek ismétlődését nem tiltja, de „a viselkedés kiszámíthatatlan”: egyes értelmezők az utolsó értéket tartják meg, mások hibát jeleznek. Ezért az ismétlődő kulcsot kerülni kell.

Végigvezetett példa: a Kurzuspont kurzusadata

A Kurzuspont szerződése a kurzus objektumáról:

Mező	Típus	Kötelező?	Megjegyzés
id	szöveg	igen	azonosító, nem szám
cim	szöveg	igen
ferohely	szám	igen	egész szám
jelentkezett	szám	igen	legfeljebb ferohely
oktato	szöveg vagy null	igen (de lehet null)	null = még nincs kijelölve
temak	szöveglista	nem	hiányozhat

Egy kliens ebből tudja, hogy az oktato mezőt mindig meg kell találnia, de az értéke null is lehet, a temak viszont hiányozhat is. Ezt a táblázatot egy minta JSON nem pótolná.

Gyakori tévhitek

Állítás	Pontosítás
„A JSON maga az API.”	A JSON adatformátum; az API a műveleteket és a szerződést is meghatározza.
„A Content-Type minden mező jelentését leírja.”	Csak a törzs formátumát jelzi.
„Az XML és a HTML ugyanaz.”	Mindkettő jelölőnyelv, de más célra és más szabályokkal készültek.
„Egy mintaválaszból minden lehetséges állapot kiderül.”	A hiányzó mezők és hibák külön leírást kérnek.
„A JSON-ban a null és a hiányzó mező ugyanaz.”	Két külön állapot; a szerződésnek kell meghatároznia.

Röviden

• A strukturált adat nevesített mezőkkel, típusokkal és listákkal teszi gépileg feldolgozhatóvá a választ.
• A JSON-nak hat adattípusa van; szigorú szintaxisa miatt a kis hiba is értelmezhetetlenné teszi.
• A null és a hiányzó mező, a szám és a számot tartalmazó szöveg nem azonos.
• Az XML elemekkel és attribútumokkal dolgozik; dokumentumszerű vagy XML-alapú rendszerekben használatos.
• A formátum nem szerződés: a mezők jelentését külön kell rögzíteni.

Ellenőrző kérdések

1. Mi a különbség a "ferohely": 40 és a "ferohely": "40" között?
2. Mit jelent az, hogy egy mező null, és miben más, mint egy hiányzó mező?
3. Miért hibás JSON a {"cim": "x",}?
4. Mi az a plusz információ, amit a Content-Type nem mond meg?

Tanulási források

• The JSON Data Interchange Format, RFC 8259 — a JSON hivatalos leírása, angolul.
• Extensible Markup Language (XML) 1.0 — a W3C ajánlása; haladó olvasmány.