JSON vs YAML vs XML: Welches Datenformat solltest du wirklich verwenden?
Ein ehrlicher Vergleich von JSON, YAML und XML — wann jedes Format glänzt, wo es schwächelt, und wie du das richtige für dein Projekt wählst.
Alle paar Monate startet jemand in meinem Team eine Debatte über Datenformate. "Warum nutzen wir hier JSON? YAML ist doch viel übersichtlicher." Oder: "XML hat Schemas, das sollten wir stattdessen verwenden."
Die Wahrheit ist: Es gibt kein universell bestes Format. Jedes existiert, weil es eine bestimmte Reihe von Problemen richtig gut löst. Lass mich aufschlüsseln, wann welches Format tatsächlich Sinn macht.
Schnelle Entscheidungsmatrix
| Eigenschaft | JSON | YAML | XML | |-------------|------|------|-----| | Lesbarkeit | Gut | Sehr gut | Schlecht | | Parsing-Geschwindigkeit | Schnell | Mittel | Langsam | | Kommentare | Nein | Ja | Ja | | Schema-Validierung | JSON Schema | Begrenzt | XSD (mächtig) | | Datentypen | Einfach | Reichhaltig | String-basiert | | Whitespace-sensitiv | Nein | Ja (Vorsicht!) | Nein | | Dateigröße | Klein | Am kleinsten | Groß | | Browser-native Unterstützung | Ja | Nein | Teilweise | | Am besten für | APIs, Configs | Configs, DevOps | Dokumente, Enterprise |
JSON: Die Lingua Franca des Webs
JSON hat das Web gewonnen. Jede API spricht es, jeder Browser parst es nativ, und jede Sprache hat eingebaute Unterstützung. Wenn du eine REST-API baust, ist die Entscheidung schon getroffen.
Wo JSON glänzt:
- API-Responses und Requests
- Paketmanifeste (
package.json,composer.json) - Datenaustausch zwischen Services
- Überall, wo schnelles Parsing nötig ist
Wo es wehtut: keine Kommentare. Du kannst deine JSON-Konfigdatei nicht annotieren, um zu erklären, warum ein Wert so gesetzt ist. Manche umgehen das mit "_comment"-Keys, aber das ist ein Hack.
YAML: Die menschenfreundliche Option
YAML wurde entworfen, um von Menschen gelesen zu werden. Keine geschweiften Klammern, keine Anführungszeichen bei den meisten Strings, und du kannst überall Kommentare hinzufügen. DevOps-Teams lieben es — Kubernetes, Docker Compose, GitHub Actions, Ansible — alle haben YAML gewählt.
Aber YAML hat eine Falle: Whitespace zählt. Eine falsche Einrückung und deine gesamte Config ist kaputt. Und die Fehlermeldungen? Oft wenig hilfreich. "Mapping values are not allowed here" sagt dir nicht viel bei 200 Zeilen Config.
Außerdem kann YAMLs Typkonvertierung überraschen. yes wird zu true. 3.10 wird zu 3.1. Norwegens Ländercode NO wird zu false. Das sind keine Bugs — das sind Features, die im ungünstigsten Moment zubeißen.
XML: Das Enterprise-Arbeitstier
XML bekommt heutzutage viel Kritik, und teilweise ist sie verdient. Es ist wortreich. Ein einfaches Key-Value-Paar in JSON ist eine Zeile; in XML sind es drei.
Aber XML kann Dinge, die die anderen nicht können. XSD-Schemas bieten mächtige Validierung — du kannst Datentypen, Muster, Pflichtfelder und sogar Wertbereiche erzwingen. XSLT ermöglicht Dokumenttransformationen. Namespaces verhindern Namenskollisionen beim Kombinieren von Dokumenten aus verschiedenen Quellen.
Wenn du im Gesundheitswesen (HL7), Finanzbereich (FIXML) oder Verlagswesen (DocBook) arbeitest, geht XML nirgendwohin. Diese Branchen haben XML wegen seiner Strenge gewählt, und diese Strenge ist genau das, was sie brauchen.
Wann was verwenden
Wähle JSON, wenn:
- Web-APIs gebaut werden
- Einfache Konfiguration gespeichert wird
- Daten zwischen Frontend und Backend ausgetauscht werden
- Schnelles Parsing und breite Sprachunterstützung nötig sind
Wähle YAML, wenn:
- CI/CD-Pipelines geschrieben werden
- Kubernetes oder Docker konfiguriert wird
- Menschlich bearbeitete Config-Dateien mit hilfreichen Kommentaren
- Mehrzeilige Strings ohne Escape-Zeichen nötig sind
Wähle XML, wenn:
- Mit Enterprise-Systemen gearbeitet wird, die es erfordern
- Mächtige Schema-Validierung nötig ist
- Dokumente mit gemischtem Inhalt (Text mit eingebetteten Daten)
- Namespaces zum Kombinieren von Dokumenttypen nötig sind
Zwischen Formaten konvertieren
Die praktische Realität: Du wirst oft zwischen Formaten konvertieren müssen. Vielleicht migrierst du eine alte XML-Config zu YAML, oder du musst YAML in JSON für eine API umwandeln.
Die Struktur lässt sich ziemlich sauber zwischen allen drei mappen. Objekte werden zu Maps werden zu Elementen. Arrays werden zu Sequenzen werden zu wiederholten Elementen. Die kniffligen Stellen sind Attribute in XML (keine direkte Entsprechung in JSON oder YAML) und Kommentare (gehen bei der Konvertierung zu JSON verloren).
Du kannst auch zwischen XML und JSON oder CSV und JSON konvertieren, wenn du mit tabellarischen Daten arbeitest.
Die echte Antwort
Verwende, was dein Ökosystem erwartet. Wenn du Kubernetes-Configs schreibst, nimm YAML. Wenn du eine Web-API baust, nimm JSON. Wenn du im Enterprise-Gesundheitswesen bist, nimm XML.
Kämpfe nicht gegen die Konventionen deiner Tools und deines Teams. Das beste Datenformat ist das, das alle in deinem Projekt bereits verstehen.
Datenformat-Debatten machen Spaß, aber sie sind selten so wichtig, wie wir denken. Wähle das, was zu deinem Anwendungsfall passt, sei konsequent dabei, und mach weiter mit echten Problemen. Deine Nutzer kümmern sich nicht darum, ob deine Config-Datei geschweifte Klammern oder Einrückungen verwendet.