Die kurze Antwort: JSON ist die sicherere Wahl für den Datenaustausch zwischen Maschinen; YAML ist die sicherere Wahl für Konfigurationen, die von Menschen manuell bearbeitet werden. Es läuft auf eine einzige Designentscheidung hinaus: wo das jeweilige Format seine Struktur verbirgt. JSON befestigt das Gerüst außen an, in Form von Klammern, die man sehen kann. YAML versteckt es in den Wänden, in Form von Leerzeichen, die man nicht sieht. Beide sind Datenserialisierungsformate, die dieselbe Aufgabe erfüllen – weshalb die Wahl so oft aus Gewohnheit statt aus Überlegung getroffen wird und so viele Teams am Ende beides pflegen. So treffen Sie die richtige Entscheidung.
JSON steht für JavaScript Object Notation und leitet sich, wie der Name schon sagt, von JavaScript-Datenformaten ab. Es ist ein offener Standard: leichtgewichtig, textbasiert und mit einem bewusst begrenzten Satz an Datentypen. Kurze Syntax, einfache Struktur, sehr gut lesbar.
Es wird verwendet, um Daten an einen Server und zurück an den Client zu senden – wie ein Umschlag, der die Daten auf ihrem Weg zwischen den Kommunikationspartnern enthält. Programmierer nutzen es in mobilen Apps, in Dokumentendatenbanken wie MongoDB (die ein binäres, JSON-ähnliches Format namens BSON speichert), in Message Queues und Log-Pipelines sowie in anwenderorientierten REST-APIs als benutzerfreundlichere Alternative zu XML. Es ist das Standard-Payload-Format für REST-APIs und wird von jedem Browser nativ geparst.
Laut dem Entwickler von JSON, Douglas Crockford, wurde eine Sprache mit denselben Prinzipien bereits 1996 bei Netscape verwendet, doch JSON etablierte sich erst um 2001 als Mainstream-Syntax. Es ist sprachunabhängig und funktioniert daher mit jeder Programmiersprache; diese Portabilität ist der Hauptgrund für seine weite Verbreitung.
Eine .json -Datei ist eine reine Textdatei, die ein einzelnes JSON-Dokument enthält, mit der Endung .json gespeichert wird und in jedem Editor lesbar ist. Sie verwendet eine kurze Liste von Datentypen: Strings, Zahlen, Objekte, Arrays, Booleans und Null. Die Syntax lehnt sich an Konventionen an, die Programmierern der C-Sprachfamilie – C, C++, C#, Java, JavaScript, Perl, Python und andere – vertraut sind. Wie es auf der offiziellen JSON-Website heißt, ist ein Objekt eine ungeordnete Menge von Name/Wert-Paaren, die mit einer geschweiften Klammer beginnt und endet, wobei jeder Name von einem Doppelpunkt gefolgt wird und die Paare durch Kommas getrennt sind.
Die funktionale Grammatik passt auf diese eine Seite unter json.org: nicht nur eine Zusammenfassung der Spezifikation, sondern die Spezifikation selbst. Das Format ist zudem offiziell standardisiert als ECMA-404 (2. Ausgabe, 2017) und IETF RFC 8259 (2017), aber die Grammatik, die diese Dokumente festlegen, ist dieselbe kompakte. Behalten Sie das im Hinterkopf, wenn später die YAML-Spezifikation auftaucht.
Dieselben Daten, zuerst in JSON, unter Verwendung einiger Informationen über die Heavy-Metal-Band Metallica:
{
"band": "Metallica",
"formed": 1981,
"origin": "Los Angeles, California",
"genres": ["thrash metal", "heavy metal"],
"active": true,
"members": [
{ "name": "James Hetfield", "role": "vocals, rhythm guitar", "joined": 1981 },
{ "name": "Lars Ulrich", "role": "drums", "joined": 1981 },
{ "name": "Kirk Hammett", "role": "lead guitar", "joined": 1983 },
{ "name": "Robert Trujillo", "role": "bass", "joined": 2003 }
],
"disbanded": null
}Geschweifte Klammern begrenzen das Objekt und die Arrays; jedes Element steht in Anführungszeichen; ein Doppelpunkt trennt jeden Namen von seinem Wert, und ein Komma trennt die Paare voneinander. Das gesamte Grundgerüst liegt offen, sodass man es direkt nachvollziehen kann.
Es funktioniert, weil die Syntax kompakt und für Menschen lesbar ist, das Markup minimal ist, die Verarbeitung in jeder Sprache schnell erfolgt und die Unterstützung nahezu universell ist.
Es hat drei Schwachstellen. Die Datentypen beschränken sich auf Strings, Zahlen, Objekte, Arrays, Booleans und Null; alles Komplexere muss also als String kodiert und am anderen Ende manuell dekodiert werden. Es gibt keine Unterstützung für Namespaces, Kommentare oder Attribute, und das Fehlen von Kommentaren macht sich besonders in Konfigurationsdateien bemerkbar. Zudem ist die Struktur bewusst einfach gehalten, weshalb sich bei komplexen Konfigurationen oft zusätzliche Konventionen darüberlegen.
YAML stand ursprünglich für Yet Another Markup Language, bis die Bedeutung in YAML Ain't Markup Language geändert wurde, um den Fokus stärker auf Daten statt auf Dokumente zu legen. Es ist ein sehr gut lesbares, leichtgewichtiges Format, das meist zur Speicherung von Konfigurationen für DevOps-Tools wie Elasticsearch, Docker, Kubernetes, Prometheus und Ansible verwendet wird.
Wie es auf der offiziellen Website, die selbst in YAML geschrieben ist, heißt: YAML ist eine menschenfreundliche Datenserialisierungssprache für alle Programmiersprachen. Es handelt sich um eine Sprache zur Datenserialisierung, die jedoch ebenso häufig für Konfigurationsdateien eingesetzt wird. Wir betrachten sie hier unter dem Aspekt der Datenserialisierung.
YAML wurde erstmals 2001 veröffentlicht. Die Gründungsmitglieder Ingy dot Net, Clark Evans und Oren Ben-Kiki schlossen sich zusammen, um etwas Einfacheres als XML zu entwickeln. Seitdem hat es sich zum Standard-Konfigurationsformat für den Großteil der DevOps-Toolchain entwickelt, was bedeutet, dass die Wahl oft schon vor Ihrem Einstieg für Sie getroffen wurde.
Eine YAML-Datei ist eine reine Textdatei, die als .yaml oder .ymlgespeichert wird und ein oder mehrere YAML-Dokumente enthält. Eine Datei kann mehrere Dokumente umfassen, die durch eine Zeile mit drei Bindestrichen getrennt sind; so bündelt beispielsweise ein Kubernetes-Manifest ein Deployment und einen Service. Da es Kommentare unterstützt, ist die Bearbeitung besonders angenehm.
YAML ist eine Obermenge von JSON: Jedes gültige JSON-Dokument ist auch gültiges YAML. Daher kann eine YAML-Datei JSON-Objekte enthalten und ein YAML-Parser liest eine .json Datei unverändert. Es verarbeitet komplexe Datentypen problemlos und erlaubt eine beliebig tiefe Verschachtelung von Objekten. Genau diese Flexibilität ist der Grund, warum manche Systeme einschränken, welche YAML-Funktionen sie akzeptieren.
#).|) behält Zeilenumbrüche bei, das Größer-als-Zeichen (>) fasst sie zu einer Zeile zusammen.Dieselben Daten noch einmal, diesmal in YAML:
band: Metallica
formed: 1981
origin: Los Angeles, California
genres:
- thrash metal
- heavy metal
active: true
members:
- name: James Hetfield
role: vocals, rhythm guitar
joined: 1981
- name: Lars Ulrich
role: drums
joined: 1981
- name: Kirk Hammett
role: lead guitar
joined: 1983
- name: Robert Trujillo
role: bass
joined: 2003
disbanded: nullDrei Unterschiede fallen sofort auf. Die geschweiften und eckigen Klammern sind verschwunden, da die Einrückung die Hierarchie vorgibt. Auch die Anführungszeichen sind weg, da YAML den Typ aus dem Wert ableitet. Und die Elemente werden als Sequenz mit Bindestrichen statt als kommagetrenntes Array dargestellt, sodass das Hinzufügen eines fünften Elements ein neuer Block ist und keine Änderung an der Zeichensetzung erfordert.
Aufgeräumter, ja. Aber schauen Sie sich noch einmal an, wo das Grundgerüst geblieben ist. In der JSON-Version ist es explizit angegeben. In der YAML-Version wird es aus dem Whitespace abgeleitet – ein grundlegend anderes Versprechen.
Es funktioniert, weil die Syntax leicht lesbar ist, Einrückungen die Struktur ohne Satzzeichen verdeutlichen, Kommentare unterstützt werden, komplexe Strukturen darstellbar sind und Anker die Wiederverwendung von Blöcken ermöglichen, anstatt sie kopieren zu müssen. Diese Wiederverwendbarkeit ist ein Grund dafür, warum YAML zur Beschreibung von Infrastrukturen verwendet wird, etwa bei Kubernetes-Stacks, bei denen dieselben Einstellungen in Dutzenden von Objekten wiederkehren.
Genau dort, wo diese Flexibilität liegt, stößt es an seine Grenzen. Falsche Einrückungen oder Abstände führen zu Validierungsfehlern oder, noch schlimmer, zu einer Datei, die zwar fehlerfrei geparst wird, aber etwas völlig anderes bewirkt als beabsichtigt. Die deklarative Natur erschwert das Debugging: Es gibt keinen Code, den man Schritt für Schritt durchgehen kann, sodass Fehler erst beim Parsen oder Anwenden der Datei sichtbar werden. Und die Typinferenz birgt ihre Tücken, wie das berühmte Beispiel des Alpha-2-Ländercodes für Norwegen, NO, der als boolescher Wert „false“ interpretiert wird, sofern man ihn nicht in Anführungszeichen setzt. Streng genommen gehört dieses Verhalten zu YAML 1.1: die aktuelle Spezifikation, YAML 1.2, Revision 1.2.2 (Oktober 2021), beschränkt boolesche Werte ausschließlich auf „true“ und „false“. Diese Falle existiert in der Praxis weiterhin, da sehr viele Parser standardmäßig noch die 1.1-Semantik verwenden. In der Praxis setzt man daher NO in Anführungszeichen und macht einfach weiter.
YAML und JSON sind zwei beliebte Formate, die sich in Struktur und Nutzbarkeit ähneln. Ihre Unterschiede in Design, Syntax und Funktionalität machen die Wahl zwischen ihnen zu einer Frage des jeweiligen Einsatzzwecks.
| Merkmal | JSON | YAML |
|---|---|---|
| Syntax | Geschweifte/Eckige Klammern, Anführungszeichen und Kommas | Einrückung, Doppelpunkte und Bindestriche |
| Kommentare | Nicht unterstützt | Unterstützt mit # |
| Datentypen | Strings, Zahlen, Objekte, Arrays, Booleans, null | Die gleichen, plus Datum und Zeitstempel |
| Parsing-Geschwindigkeit | Schneller: eine kleine, eindeutige Grammatik | Langsamer: eine weit umfangreichere Spezifikation |
| Menschliche Lesbarkeit | Gut, sobald man sich an die Satzzeichen gewöhnt hat | Besser für manuelle Bearbeitung, schwerer zu erkennen bei komplexer Struktur |
| Wiederverwendung | Keine | Anker und Aliase |
| Tooling-Unterstützung | Nativ in Browsern und fast allen Standardbibliotheken | Erfordert in den meisten Sprachen eine externe Bibliothek |
| Typische Nutzung | APIs, Datenaustausch, maschinell erstellte Dateien | Konfigurationsdateien, CI-Pipelines, Infrastruktur |
Ein grundlegender Unterschied liegt allem zugrunde: JSON wurde für das Schreiben und Lesen durch Maschinen entwickelt. Daher ist die Struktur explizit definiert und lässt dem Parser keinen Spielraum für Fehlinterpretationen. YAML wurde für Menschen konzipiert; die Struktur wird hier über Leerzeichen abgebildet, wodurch die Datei eher wie eine Gliederung als wie Code aussieht.
Der Unterschied beim Parsen ergibt sich aus den Spezifikationen, nicht aus Benchmarks. Die JSON-Grammatik umfasst eine einzige Seite auf json.org. Die YAML 1.2-Spezifikation hingegen erstreckt sich über Dutzende von Seiten und deckt Anker, Tags, Block-Skalare, mehrere Dokumente und implizite Typisierung ab – das bedeutet mehr Arbeit für den Parser und mehr Fehlerquellen. Betrachten Sie den Geschwindigkeitsunterschied als einen qualitativen Unterschied und nicht als bloße Zahl: Er ist irrelevant für eine Datei, die einmal beim Start gelesen wird, aber messbar für einen Dienst, der den ganzen Tag lang Daten deserialisiert.
Das ist auch der Grund, warum sie auf unterschiedliche Weise fehlschlagen. Eine fehlerhafte JSON-Datei führt meist sofort und deutlich sichtbar zu einem Abbruch beim Parsen. Eine fehlerhafte YAML-Datei wird oft problemlos geparst, bedeutet dann aber etwas völlig anderes, weil durch eine verrutschte Einrückung ein Schlüssel unter das falsche übergeordnete Element geraten ist oder ein nicht in Anführungszeichen gesetzter Wert falsch interpretiert wurde. Stille Fehler sind die teuersten.
Abstrakt betrachtet keines von beiden. Die Frage lässt sich erst beantworten, wenn man den Anwendungsfall kennt. Richten Sie sich also nach der Funktion: Was muss das Format leisten?
JSON ist die bessere Wahl für den Datenaustausch. Es ist schnell zu parsen, wird überall ohne Abhängigkeiten unterstützt und jedes Element ist explizit abgegrenzt, was verhindert, dass ein Parser die Struktur falsch interpretiert. Der Nachteil ist die begrenzte Auswahl an Datentypen, weshalb komplexere Werte als Strings kodiert und beim Auslesen wieder dekodiert werden müssen. Wenn Sie solche Schnittstellen entwerfen, hilft Ihnen unser Vergleich von GraphQL vs. REST bei der Entscheidung zwischen den beiden führenden API-Stilen.
YAML ist die bessere Wahl für Konfigurationen, die von Menschen gepflegt werden. Es unterstützt Kommentare, lässt sich tief verschachteln, ohne dass sich Satzzeichen anhäufen, und durch Anker können gemeinsame Einstellungen zentral definiert werden. Der Nachteil ist, dass die Struktur durch Leerzeichen definiert wird; eine Datei kann also syntaktisch korrekt, aber inhaltlich falsch sein, und der Parser hat mehr Arbeit.
Kurz gesagt: Wenn ein Programm die Datei schreibt, verwenden Sie JSON. Wenn ein Mensch die Datei schreibt, verwenden Sie YAML und schalten Sie einen Validator davor.
Diese Trennung ist für uns nicht abstrakt. Als wir FlippedNormals, einen Marktplatz für Computergrafik, der aus WordPress herausgewachsen war, von Heroku auf AWS umzogen, war der Auslöser genau der oben genannte Kompromiss: Die verwalteten Dynos von Heroku boten uns kaum Kontrolle über die Skalierung, während der Katalog wuchs. Also migrierten wir die Plattform auf AWS und schlossen die erste Phase in zwei Monaten ab, parallel zu einem Datenbankumzug von MySQL auf PostgreSQL. Eine Infrastrukturmigration wie diese ist der Punkt, an dem die YAML-Hälfte dieses Artikels aufhört, Theorie zu sein: Das Deployment wird in Konfigurationsdateien beschrieben, geprüft und versioniert, die von Hand bearbeitet werden.
Die JSON-Hälfte tauchte im selben System auf, in den Payloads, die die Dienste des Marktplatzes untereinander austauschten: maschinell geschrieben, tausendfach gelesen, niemals von Hand bearbeitet. Dasselbe System, beide Formate, jedes für den Zweck, für den es am besten geeignet ist.
Für die meisten Teams ist dies keine ästhetische Entscheidung. Die Rechnung wird an fünf Stellen fällig.
Konfigurationsfehler in der Produktion. Da YAML empfindlich auf Leerzeichen reagiert und Typen automatisch erkennt, kann eine Datei gleichzeitig gültig und fehlerhaft sein. Kein Parser erkennt diese Art von Fehlern: Das gelingt nur mit einer Schema-Prüfung oder wenn das Deployment am Nachmittag fehlschlägt. Jedes Repository, in dem YAML die Infrastruktur steuert, benötigt eine Schema-Validierung und einen Formatierer in der Continuous Integration, und das kostet Zeit für die Einrichtung und Wartung.
Sicherheit beim Parsen. Der Full-Loader von YAML kann beliebige Objekte aus einem Dokument erstellen. Sobald die Eingabe nicht vertrauenswürdig ist, wird ein einfacher Parsing-Vorgang so zur Erlaubnis, beliebigen Code auszuführen. Deshalb bieten Bibliotheken eine sichere Ladefunktion an, wobei PyYAMLs safe_load am bekanntesten ist. Genau deshalb sollte dies der Standard in jeder Codebasis sein, die YAML-Dateien liest, die nicht selbst erstellt wurden. JSON hat diese Schwachstelle nicht, da das Format keine Typen zur Instanziierung beschreiben kann.
Einarbeitungszeit. JSON ist jedem vertraut, der schon einmal eine API genutzt hat. YAML hingegen bietet Anker, Aliase, Block-Skalare und mehrere Dokumente pro Datei – ein neuer Mitarbeiter begegnet all dem bereits in seiner ersten Woche in einer Kubernetes-Umgebung. Planen Sie Zeit für die Einarbeitung ein oder legen Sie eine dokumentierte Teilmenge fest und halten Sie diese schriftlich fest.
Parsing-Aufwand bei hoher Skalierung. Bei einer Konfigurationsdatei, die nur beim Systemstart gelesen wird, spielt der Parsing-Aufwand keine Rolle. Bei einem Dienst, der tausende Payloads pro Sekunde deserialisiert, ist das jedoch anders, und die kompaktere JSON-Grammatik ist hier effizienter zu verarbeiten.
Umgebungen mit gemischten Formaten. Das teuerste Ergebnis ist nicht die Wahl eines Formats, sondern die Nutzung beider: Konfigurationen in YAML, Fixtures in JSON, eine Konvertierungsschicht dazwischen und zwei Sätze von Validierungsregeln, die nach anderthalb Jahren auseinanderdriften. Entscheiden Sie sich für ein Format pro Zweck, halten Sie die Entscheidung schriftlich fest und validieren Sie jedes mit einem Schema: JSON Schema für die JSON-Seite und eines der YAML-Schema-Tools für die andere.
Vier Fragen, die wir klären, bevor wir uns für ein Serialisierungsformat für ein Projekt entscheiden.
Meistens führen die Antworten nicht zu einem einzigen Format für das gesamte System. Auf den meisten Plattformen, die wir entwickeln, ist die Aufteilung dieselbe: YAML für alles, was von Menschen gepflegt wird – Pipelines, Manifeste, Umgebungskonfigurationen – und JSON für den Datenaustausch zwischen Diensten. Der Fehler, den wir am häufigsten sehen, ist nicht die Wahl des falschen Formats, sondern dass beide Formate für dieselbe Aufgabe verwendet werden, ohne dass festgelegt wird, was wohin gehört.
Nein. JSON lässt sich schneller parsen, da die Grammatik auf einer einzigen Seite Platz findet und eindeutig ist, während die YAML-Spezifikation weitaus umfangreicher ist und eine Typinferenz erfordert. Bei einer Konfigurationsdatei, die nur einmal beim Start gelesen wird, ist dieser Unterschied vernachlässigbar; bei einem Dienst, der kontinuierlich Payloads verarbeitet, spielt er jedoch eine Rolle.
Ja. YAML ist eine Obermenge von JSON, daher ist jedes gültige JSON-Dokument auch gültiges YAML, und ein YAML-Parser liest eine .json Datei unverändert. Umgekehrt gilt dies nicht: Ein JSON-Parser kann kein YAML lesen.
.json Datei?Eine reine Textdatei, die ein einzelnes JSON-Dokument enthält und mit der Endung .json gespeichert wird. Sie enthält an der Wurzel ein Objekt oder ein Array, verwendet Anführungszeichen für Schlüssel und Werte und lässt sich in jedem Texteditor öffnen.
Eine reine Textdatei, die als .yaml oder .yml gespeichert wird und ein oder mehrere YAML-Dokumente enthält. Sie verwendet Einrückungen anstelle von Klammern, unterstützt Kommentare und ist das Standard-Konfigurationsformat für Tools wie Kubernetes, Docker Compose und Ansible.
YAML, da das gesamte Ökosystem darin geschrieben ist und Manifeste von Menschen bearbeitet und überprüft werden. Kubernetes akzeptiert zwar das JSON-Äquivalent, aber jedes Beispiel, jedes Tutorial und jedes generierte Manifest, auf das Sie stoßen, wird in YAML vorliegen.
In jedem Repository, in dem mehr als eine Person YAML bearbeitet: ja. Ein Formatter in Kombination mit einem Linter in der CI erkennt Einrückungs- und Typinferenzfehler, die ein Parser zwar klaglos akzeptiert, die ein Cluster später jedoch ablehnt.
Nur mit einem sicheren Loader. Der vollständige Loader kann beliebige im Dokument beschriebene Objekte instanziieren, sodass das Parsen einer nicht vertrauenswürdigen Datei Code ausführen kann. Verwenden Sie die sichere Variante, die Ihre Bibliothek bereitstellt, wie zum Beispiel bei PyYAML safe_load, sofern die Datei nicht aus Ihrem eigenen Repository stammt.
Immer dann, wenn ein Programm die Datei schreibt oder liest und kein Mensch: bei API-Payloads, Message Queues, Log-Zeilen, Test-Fixtures oder Browser-Speicher. Greifen Sie zu YAML, wenn ein Mensch die Datei pflegt und Kommentare sowie eine übersichtliche Struktur benötigt.
Ja, und die meisten YAML-Bibliotheken erledigen das mit einer einzigen Zeile Code. Da beim Konvertieren von YAML zu JSON Kommentare und Anker verloren gehen, sollten Sie YAML immer als Quelle und JSON als generiertes Artefakt betrachten – niemals umgekehrt.
Die Wahl eines Serialisierungsformats ist eine kleine Entscheidung mit weitreichenden Folgen und meist der am wenigsten interessante Teil einer viel größeren Architekturfrage. Wenn Sie abwägen, wie Ihre Dienste Daten austauschen und speichern sollen, steht Ihnen unser Engineering-Team gerne für ein Gespräch zur Verfügung.
Inhaltsautor und Produzent digitaler Medien mit Interesse an der symbiotischen Beziehung zwischen Technologie und Gesellschaft. Bücher, Musik und Gitarren sind eine Konstante.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
