JSON vs. YAML vs. XML: Wann du welches Format wirklich verwenden solltest

JSON, YAML und XML können im Grunde alle dieselben zugrunde liegenden Daten abbilden – verschachtelte Objekte, Listen, Schlüssel-Wert-Paare, einfache Werte –, weshalb die Wahl zwischen ihnen so oft eher aus Gewohnheit oder dem Standard eines Frameworks resultiert als aus einer durchdachten Entscheidung. Doch die drei wurden zu unterschiedlichen Zeiten für unterschiedliche primäre Einsatzzwecke entworfen, und diese ursprünglichen Designziele zeigen sich bis heute als reale, praktische Unterschiede: Welches Format lässt sich angenehm von Hand bearbeiten, welches kann eine Maschine streng validieren, welches bleibt auch bei tiefer Verschachtelung noch lesbar, und für welches gibt es bereits ein ganzes Ökosystem an Werkzeugen. Sich an diesen Unterschieden zu orientieren, statt an der Gewohnheit, ist das, was eine Formatwahl wirklich gut macht statt nur konventionell.

JSON wurde direkt aus der Objekt-Literal-Syntax von JavaScript abgeleitet, und genau dieser Ursprung ist der Grund, warum es zum Standardformat für den Datenaustausch bei Web-APIs wurde: Jede JavaScript-Umgebung kann es nativ parsen, ganz ohne Bibliothek, seine Grammatik ist klein genug, um sie in praktisch jeder anderen Sprache an einem Nachmittag korrekt zu implementieren, und seine strengen Regeln – keine Kommentare, keine abschließenden Kommas, Schlüssel ausschließlich in doppelten Anführungszeichen – lassen einem JSON-Parser kaum Mehrdeutigkeit zum Auflösen. Das macht JSON schnell zu parsen und leicht korrekt zu erzeugen. Genau diese Strenge ist zugleich JSONs größte Schwäche für alles, was ein Mensch direkt von Hand bearbeiten soll: Keine Kommentare bedeutet, dass es keine Möglichkeit gibt, in einer Konfigurationsdatei eine erklärende Notiz zu hinterlassen, und die zeichenlastige, verschachtelte Klammersyntax wird ab etwa drei oder vier Verschachtelungsebenen visuell wirklich schwer zu verfolgen.

Das ist auch der Grund, warum JSON die Kommunikation zwischen Maschinen dominiert – API-Antworten, Datenaustausch zwischen Diensten, alles, was in erster Linie von Code erzeugt und verarbeitet wird statt von einem Menschen gelesen und bearbeitet zu werden –, während es für Konfigurationsdateien, die ein Mensch von Hand pflegen soll, eine eher unbeholfene Wahl bleibt.

YAML wurde mit der entgegengesetzten Priorität entworfen: menschliche Lesbarkeit und einfache manuelle Bearbeitung, auf Kosten einer deutlich komplexeren Parsing-Spezifikation als der von JSON. Es nutzt Einrückung statt Klammern zur Darstellung von Verschachtelung, unterstützt echte Kommentare mit `#` und erlaubt im Regelfall Strings ohne Anführungszeichen – all das lässt eine gut formatierte YAML-Datei fast wie strukturierte Notizen in Klartext lesen statt wie Code. Genau deshalb wurde YAML zum Standard für Konfigurationsdateien in einem riesigen Teil der Entwickler-Tools: CI/CD-Pipeline-Definitionen, Container-Orchestrierungs-Manifeste, Anwendungskonfiguration, die ein Mensch wirklich lesen und direkt anpassen muss. Der Kompromiss: Weil YAML sich für seine Struktur auf Leerraum verlässt, ist es beim manuellen Bearbeiten wirklich fehleranfällig – eine einzige falsch platzierte Einrückung ändert stillschweigend, zu welchem Block etwas gehört, statt einen offensichtlichen Fehler zu werfen –, und seine großzügigere, funktionsreichere Spezifikation hat über die Jahre zu echten, dokumentierten Inkonsistenzen beim Parsen zwischen verschiedenen YAML-Bibliotheken geführt – eine Mehrdeutigkeit, für die JSONs deutlich strengere Grammatik schlicht keinen Raum lässt.

XML ist älter als JSON und YAML und wurde nochmal mit einer anderen Priorität entworfen: strikte, überprüfbare Dokumentstruktur, mit einem ausgereiften Ökosystem begleitender Standards – Schemasprachen, die die Struktur eines Dokuments validieren können, noch bevor Anwendungscode es überhaupt berührt, XPath zum Abfragen innerhalb eines Dokuments, Namensräume zum Kombinieren von Vokabularen aus unterschiedlichen Quellen ohne Namenskollisionen. Diese Tiefe des Tooling-Ökosystems wird von JSON oder YAML in unternehmens- und dokumentzentrierten Kontexten bis heute wirklich nicht erreicht: Branchen mit strengen Anforderungen an den Datenaustausch, standardisierte Dokumentformate und langlebige Altsysteme, die darauf aufbauen, setzen weiterhin auf XML – gerade wegen dieser Reife bei Validierung und Tooling, nicht aus reiner Trägheit. Der bekannte Kompromiss ist die Umständlichkeit: Dieselben verschachtelten Daten in XML darzustellen, braucht in der Regel spürbar mehr Zeichen als das entsprechende JSON, da jeder Wert ein öffnendes und ein schließendes Tag braucht statt eines einzelnen Satzzeichens – der Hauptgrund, warum XML seine Rolle als Standardformat für APIs an JSON verlor, als Webdienste reiften und Payload-Größe sowie Parsing-Einfachheit wichtiger wurden als dokumentartige Validierung.

Für den Body einer API-Anfrage oder -Antwort ist JSON heute fast immer die richtige Standardwahl – es ist das, was die meisten Client-Bibliotheken, die meiste Dokumentations-Tooling und die meisten Entwickler auf der anderen Seite einer Integration reibungslos erwarten. Für eine Konfigurationsdatei, die eine Person regelmäßig lesen und von Hand bearbeiten wird – CI-Pipelines, Anwendungskonfiguration, Infrastructure-as-Code-Definitionen –, verdienen sich YAMLs Kommentare und die übersichtlichere Verschachtelung wirklich ihren Platz, vorausgesetzt, das umgebende Tooling validiert die Syntax sorgfältig, denn genau dort schlägt YAMLs Anfälligkeit für Leerraumfehler am härtesten zu. Für ein dokumentzentriertes Format mit echtem Bedarf an strikter Schemavalidierung, Namensräumen für kombinierte Vokabulare oder der Einbindung in ein bestehendes XML-basiertes Unternehmenssystem ist XMLs Umständlichkeit ein vertretbarer Preis für eine Tooling-Reife, die keines der beiden anderen Formate vollständig nachbildet. Die Formatwahl, die einem Projekt wirklich dient, ist die, die zu dem passt, wer – oder was – die Datei am häufigsten liest und schreibt, nicht die, die gerade als angesagtester Standard gilt.