YAML
2 tools
Gegevensserialisatieformaten
Gegevensserialisatie is het proces waarbij gestructureerde data wordt omgezet naar een formaat dat opgeslagen of verzonden kan worden en later weer kan worden gereconstrueerd. Verschillende formaten maken verschillende afwegingen tussen leesbaarheid voor mensen, parseerbaarheid door machines, expressiviteit en bestandsgrootte.
JSON, YAML, TOML en XML zijn de vier dominante tekstgebaseerde serialisatieformaten in softwareontwikkeling. Elk heeft sterke punten die het de beste keuze maken voor specifieke situaties — inzicht in die afwegingen helpt je het juiste formaat voor elke taak te kiezen.
JSON en YAML naast elkaar
JSON en YAML vertegenwoordigen hetzelfde datamodel. YAML is een strikte superset van JSON — elk geldig JSON-document is ook geldig YAML. Hieronder staat dezelfde configuratie uitgedrukt in beide formaten:
{
"server": {
"host": "localhost",
"port": 8080,
"debug": true
},
"database": {
"url": "postgres://localhost/mydb",
"pool": 10
}
}server: host: localhost port: 8080 debug: true database: url: postgres://localhost/mydb pool: 10
YAML gebruikt inspringing in plaats van accolades en haakjes, en laat aanhalingstekens weg bij de meeste stringwaarden. Dit maakt het compacter en leesbaarder voor door mensen bewerkte bestanden, maar introduceert gevoeligheid voor inspringing.
Formaatoverzicht
| Formaat | Leesbaarheid | Commentaar | Arrays | Beste voor |
|---|---|---|---|---|
| JSON | ★★★☆☆ | Geen commentaar | Ingebouwd | API's, data-uitwisseling |
| YAML | ★★★★★ | Ja (#) | Ingebouwd | Configuratiebestanden, IaC |
| TOML | ★★★★☆ | Ja (#) | Ingebouwd | App-config (Rust, Python) |
| XML | ★★☆☆☆ | Ja (<!-- -->) | Herhaalde elementen | Documenten, SOAP, SVG |
YAML-valkuilen
YAML is krachtig, maar heeft bekende randgevallen die ontwikkelaars verrassen. Dit zijn de meest voorkomende:
De kale waarde 'NO' wordt in YAML 1.1 geïnterpreteerd als booleaanse false. Landcodes zoals NO (Noorwegen), OFF, FALSE en N worden allemaal geparsed als false. In YAML 1.2 is dit opgelost, maar veel parsers hanteren nog steeds de 1.1-regels. Zet altijd aanhalingstekens om dubbelzinnige strings.
YAML gebruikt inspringing om structuur te definiëren. Één extra spatie of een tab-teken kan de betekenis van een document volledig veranderen. Tabs zijn verboden als inspringing in YAML — alleen spaties zijn toegestaan.
Kale waarden die eruitzien als getallen, booleans of null worden automatisch omgezet. '1.0' wordt een float, '2024-01-01' wordt in sommige parsers een datumobject. Zet aanhalingstekens om waarden die je als string wilt bewaren.
De YAML-specificatie verbiedt tab-tekens voor inspringing expliciet. Editors die spaties automatisch omzetten naar tabs, breken je YAML-bestand stilzwijgend. Stel je editor in om spaties te gebruiken in YAML-bestanden.
YAML heeft twee indicatoren voor meerregelige strings: | (letterlijk blok, behoudt regeleinden) en > (gevouwen blok, converteert regeleinden naar spaties). Ze door elkaar gebruiken levert stilzwijgend verkeerde uitvoer op.
YAML-ankers (&) en aliassen (*) maken hergebruik van knooppunten mogelijk, wat krachtig is maar cirkelverwijzingen kan veroorzaken die leiden tot oneindige lussen of geheugenuitputting in eenvoudige parsers. Valideer verankerde YAML uit niet-vertrouwde bronnen.
Functies die uniek zijn voor YAML
Commentaar
YAML ondersteunt commentaar met het #-teken. Dit is een van de grootste praktische voordelen ten opzichte van JSON voor configuratiebestanden — je kunt je instellingen inline documenteren. Commentaar kan op een eigen regel staan of na een waarde.
Ankers en aliassen
Met YAML kun je een knooppunt eenmalig definiëren met &ankernaam en het overal hergebruiken met *ankernaam. Dit elimineert herhaling in complexe configuraties. Kubernetes en Docker Compose gebruiken ankers uitgebreid voor gedeelde servicedefinities.
Meerregelige strings
YAML ondersteunt blokvariabelen met twee modi: het letterlijke blok (|) behoudt regeleinden precies zoals geschreven, handig voor scripts en sjablonen. Het gevouwen blok (>) vouwt lange strings samen tot één regel, handig voor lange beschrijvingen in proza.
Wanneer je moet converteren
GitHub Actions, GitLab CI en CircleCI gebruiken YAML van nature. Bij het programmatisch genereren van pipeline-configuraties is het vaak eenvoudiger een JSON-object op te bouwen en dit naar YAML te converteren voor de uiteindelijke uitvoer.
Kubernetes-resources worden gedefinieerd in YAML, maar Helm-charttemplating en sommige tools produceren JSON. Converteren tussen formaten laat je API-reacties inspecteren en standaard JSON-tooling gebruiken.
REST API's retourneren JSON. Bij het doorgeven van die data aan YAML-gebaseerde configuratiesystemen (Ansible, Salt, Kubernetes) overbrugt een converter het verschil zonder handmatige herformattering.
Migreren van de ene tool naar de andere betekent vaak het omzetten van het configuratieformaat. Converteren tussen JSON en YAML laat je snel wisselen tussen ecosystemen (Node.js → Python, Docker → Kubernetes).
JSON Schema-tooling is volwassener dan YAML Schema. Een veelvoorkomend patroon is configuratie schrijven in YAML voor leesbaarheid, converteren naar JSON voor validatie tegen een schema, en dan terugconverteren voor implementatie.
Interne tooling kan YAML-configuraties verbruiken terwijl externe API's JSON vereisen. Een converter in de build-pipeline houdt beide representaties gesynchroniseerd zonder dubbele bestanden te onderhouden.
Veelgestelde vragen
Ja. YAML 1.2 is een strikte superset van JSON — elk geldig JSON-document is ook geldig YAML. YAML 1.1 (nog steeds gebruikt door veel parsers) heeft echter een paar randgevallen waarbij geldig JSON geen geldig YAML 1.1 is.
YAML ondersteunt commentaar, JSON niet. YAML is ook compacter voor diep geneste structuren. Deze twee eigenschappen maken het de voorkeurskeuze voor door mensen bewerkte configuratiebestanden (Docker, Kubernetes, GitHub Actions).
TOML (Tom's Obvious Minimal Language) is ontworpen voor configuratiebestanden. Het heeft een duidelijke, INI-achtige syntaxis met expliciete typen en geen dubbelzinnigheid. Het is de standaard voor Rust- (Cargo.toml) en Python- (pyproject.toml) projecten.
Zelden, maar het is mogelijk. JSON behoudt de volgorde van sleutels in de meeste parsers (hoewel de specificatie zegt dat het ongeordend is). YAML ondersteunt ankers en tags die geen JSON-equivalent hebben. Voor betrouwbare heen-en-terugconversie, houd je aan de gemeenschappelijke subset.
JSON.stringify converteert undefined-waarden naar null in arrays en laat ze weg uit objecten. Als je onverwachte nulls of ontbrekende sleutels ziet in JSON-uitvoer, bevatte het JavaScript-bronobject waarschijnlijk undefined-eigenschappen.
Ja. Omdat YAML een superset van JSON is, kun je JSON-syntaxis direct insluiten in een YAML-document. Dit wordt soms gedaan voor complexe geneste structuren waarbij de inspringing van YAML verwarrend zou zijn.