YAML

Zwei Formate, überlappende Aufgaben

JSON (JavaScript Object Notation) und YAML (YAML Ain’t Markup Language) stellen beide strukturierte Daten dar: verschachtelte Objekte, Listen, Zeichenketten, Zahlen und Booleans. Sie begegnen Ihnen in APIs, Konfigurationsdateien, CI-Pipelines, Kubernetes-Manifesten und Dokumentationsbeispielen. Die Wahl zwischen ihnen geht weniger darum, welches Format „besser“ ist, sondern wer die Datei bearbeitet, welche Werkzeuge sie konsumieren und wie streng das Parsen sein muss.

Wenn Sie bereits JSON haben und es als YAML-Einrückung prüfen möchten, konvertieren Sie mit JSON zu YAML.

JSON in Kürze

JSON entstand aus der JavaScript-Objektliteralsyntax und wurde zu einem sprachunabhängigen Austauschformat. Ein JSON-Dokument besteht aus:

• Objekten: { "key": "value" }
• Arrays: [1, 2, 3]
• Zeichenketten in doppelten Anführungszeichen
• Zahlen
• true, false und null

Wichtige Einschränkungen: keine Kommentare, keine nachgestellten Kommas in Standard-JSON, Schlüssel müssen Zeichenketten sein, und Zeichenketten nutzen eine begrenzte Escape-Syntax. Diese Einschränkungen machen Parser einfach und streng—wertvoll für Maschinen, die Daten austauschen.

Schön formatiertes JSON ist bei kleinen Dokumenten lesbar. Große Konfigurationen mit tiefer Verschachtelung werden unübersichtlich durch geschweifte Klammern, eckige Klammern und Anführungszeichen in jeder Zeile.

YAML in Kürze

YAML legt den Schwerpunkt auf menschliche Bearbeitung. Die Struktur wird vor allem durch Einrückung statt durch Klammern vermittelt. Merkmale sind unter anderem:

• Kommentare mit #
• oft unquoted Zeichenketten
• Anchors und Aliase zur Wiederverwendung
• mehrere Dokumentströme, getrennt durch ---
• explizite Typ-Tags bei fortgeschrittener Nutzung

Eine kleine Zuordnung sieht so aus:

service:
  name: api
  replicas: 3
  ports:
    - 8080
    - 8443

Dieselbe Struktur in JSON wiederholt Satzzeichen und Anführungszeichen. Für Operatoren, die täglich Manifeste bearbeiten, ist YAML’s Knappheit attraktiv.

Überlappung des Datenmodells

Im Kern können beide Formate Bäume aus Maps und Sequenzen mit skalaren Blättern ausdrücken. Round-Tripping ist für die gemeinsame Teilmenge oft möglich: Objekte, Arrays, Zeichenketten, Zahlen, Booleans und null.

Unterschiede zeigen sich an den Rändern:

• YAML kann Nicht-Zeichenketten-Schlüssel erzeugen; JSON nicht.
• YAML bietet mehr Schreibweisen für Zeichenketten (Literalblöcke, Folded Blocks).
• YAML’s „Norway problem“ und andere implizite Typisierungsfallen können unquoted NO, on oder versionsähnliche Token je nach YAML-Version und Parser in Booleans oder Zahlen verwandeln.
• JSON-Zahlen sind geradlinig; YAML kann große Ganzzahlen oder Zeitstempel in manchen Loadern besonders parsen.

Wenn Interoperabilität zählt, setzen Sie Zeichenketten, die wie Booleans, Zahlen oder Daten aussehen, in YAML in Anführungszeichen—oder generieren Sie YAML aus einer typisierten Struktur, statt mehrdeutige Skalare von Hand zu pflegen.

Kommentare und Dokumentation

JSON hat keine Standardkommentare. Teams missbrauchen manchmal "_comment"-Felder und verunreinigen damit Schemas. YAML’s #-Kommentare dokumentieren Absicht neben den Daten—warum die Replica-Anzahl 3 ist, welches Team ein Label besitzt—ohne das Informationsmodell zu ändern.

Wenn die Hauptzielgruppe Maschinen sind (APIs, Browser-fetch-Bodies), ist JSON’s Kommentarlosigkeit selten ein Problem. Wenn Menschen die Datei monatelang pflegen, verringern YAML-Kommentare den Verlust von Insiderwissen.

Werkzeuge und Ökosystem

JSON-Stärken

• allgegenwärtige Parser in jeder gängigen Sprache
• erstklassige Browser-Unterstützung (JSON.parse / JSON.stringify)
• weit verbreitete Schema-Ökosysteme (JSON Schema)
• zeilenorientierte Diffs, die trotz Klammern vertraut wirken
• Streaming-Parser für große Payloads

YAML-Stärken

• dominant in DevOps (Kubernetes, Ansible, viele CI-Systeme)
• Merges und Anchors (mächtig, manchmal überstrapaziert)
• Multi-Dokument-Dateien zum Bündeln verwandter Ressourcen
• freundlicher bei leicht verschachtelter Konfiguration

YAML-Risiken

• Spezifikationskomplexität (Unterschiede YAML 1.1 vs 1.2)
• Einrückungsfehler, die schwer zu sehen sind
• Features (Custom Tags, Merge Keys), die die Portabilität mindern
• historisch versehentliche Codeausführung in unsicheren Loadern—immer Safe-Load-APIs verwenden

Leistung und Größe

Für Wire-Protokolle ist JSON in optimierten nativen Bibliotheken meist günstiger zu parsen und vermeidet Einrückungsaufwand. Komprimiertes JSON und YAML nähern sich in der Größe an. Bei Konfiguration, die selten gelesen und oft bearbeitet wird, ist die Parse-Geschwindigkeit selten der Engpass—sondern die menschliche Fehlerrate.

Binäre Verwandte (MessagePack, CBOR, Protobuf) übertreffen beide, wenn Durchsatz dominiert. Sie sind keine Drop-in-Formate für Menschen.

Konvertierungsstrategien

Die Umwandlung JSON → YAML ist für die gemeinsame Teilmenge typischerweise verlustfrei und nützlich für Lesbarkeitsreviews. Die Umwandlung YAML → JSON kann Kommentare, Anchors und Nicht-JSON-Typen verlieren. Behandeln Sie Konvertierung als Projektion, nicht als perfektes Archiv der Autorenabsicht.

Workflow-Tipps:

1. Halten Sie eine einzige Quelle der Wahrheit (oft JSON Schema oder ein typisiertes Sprachmodell).
2. Generieren Sie das Format, das jeder Consumer braucht.
3. Wenn Menschen YAML bearbeiten müssen, validieren Sie bei jeder Änderung gegen ein Schema.
4. Vermeiden Sie, zwei Kopien desselben Dokuments von Hand zu pflegen.

Tool Plaza’s from-json-Konverter hilft Ihnen zu sehen, wie ein JSON-Payload mit einrückungsbasierter Syntax aussieht.

Wann JSON wählen

• öffentliche HTTP-APIs und Webhook-Bodies
• Browser- und Mobile-Clients
• strenger Maschinenaustausch mit minimaler Mehrdeutigkeit
• strukturierte Events an Aggregatoren loggen, die JSON Lines erwarten
• Einbettung in Sprachen, in denen JSON-Literale sauber auf native Typen abbilden

Wann YAML wählen

• Deployment- und Infrastruktur-Manifeste, die Menschen bearbeiten
• Konfigurationsdateien, die von Kommentaren profitieren
• Ökosysteme, die bereits auf YAML standardisieren
• Dokumente, bei denen Einrückungsklarheit für Ihr Team die Klammerzuordnung schlägt

Hybride Ansätze

Manche Projekte speichern kanonisches JSON in der Versionskontrolle und generieren YAML für ein bestimmtes Werkzeug. Andere akzeptieren YAML-Eingabe, normalisieren auf einen internen AST und emittieren JSON für APIs. Beides funktioniert, wenn die Pipeline automatisiert und getestet ist.

Seien Sie vorsichtig mit „JSON5“- oder „JSONC“-Erweiterungen (JSON mit Kommentaren): sie verbessern die Ergonomie, sind aber nicht universell. Dokumentieren Sie den Dialekt, wenn Sie einen übernehmen.

Bearbeitungs- und Review-Hygiene

• Nutzen Sie Editoren, die Einrückung und nachgestellte Leerzeichen in YAML hervorheben.
• Lassen Sie CI bei ungültiger Syntax vor dem Merge fehlschlagen.
• Bevorzugen Sie in YAML-Teams durchgängig 2-Space-Einrückung.
• Halten Sie Zeilen vernünftig kurz; riesige Inline-Zeichenketten gehören in Literalblöcke oder externe Dateien.
• Fügen Sie Secrets in keinem der Formate in öffentliche Repos ein—nutzen Sie Secret Manager und Referenzen.

Zusammenfassung

JSON ist das strenge, allgegenwärtige Austauschformat; YAML ist der kommentierfreundliche Konfigurationsdialekt mit reichhaltigerer—und riskanterer—Syntax. Für alltägliche Maps und Listen teilen sie ein verschachteltes Datenmodell. Wählen Sie JSON für APIs und Maschinen, YAML für von Menschen betriebene Infra-Dateien, und konvertieren Sie bewusst, wenn Sie beide Sichten derselben Struktur brauchen.