JSON vs. XML

Ursprünge: eine Auszeichnungssprache gegenüber einem Datenformat

XMLs Vorfahr ist SGML, und sein Entwurfsziel war das Auszeichnen von Dokumenten: Prosatext, der Absätze, Hervorhebungen und Struktur mischt. Deshalb unterstützt allein XML von beiden Mixed Content – Text mit Inline-Markup wie <title>Learning <em>XML</em></title> – und deshalb wuchsen Attribute, Entity-Referenzen und ein schwerfälliges Verarbeitungsmodell heran. JSON wurde um 2001 aus JavaScript-Objektliteralen herausgelöst, für genau einen Zweck: strukturierte Daten zwischen Programmen zu bewegen, mit möglichst wenig Grammatik. Mixed Content gibt es in JSON nicht, auch keine Entity-Maschinerie und keinen Dokumentbaum – Objekte, Arrays und vier skalare Typen sind das ganze Universum.

Syntax: die Tag-Steuer, Attribute und das fehlende Array

Jedes XML-Element öffnet und schließt, also kostet ein simpler Wert zwei Tags: <price>19.99</price>. XML bietet eine alternative Schreibweise – <price currency="EUR">19.99</price> –, und die Wahl zwischen Attribut und Element befeuert seit zwei Jahrzehnten Debatten ohne universelle Antwort. JSON hat genau eine Schreibweise für ein Schlüssel/Wert-Paar und eine für eine Liste. Entscheidend ist: JSON hat native Arrays; XML hat überhaupt keinen Array-Typ. Eine Liste drückt sich durch Wiederholung eines Elements aus, was bedeutet, dass jedes JSON-zu-XML-Tool sich auf eine Konvention zur Benennung und Umschließung wiederholter Elemente einigen muss.

Schemas und Namespaces: wo XML sich seinen Platz weiterhin verdient

XSD ist XMLs stiller Vorteil in Unternehmen: eine gereifte Schema-Sprache mit abgeleiteten Typen, Kardinalitätsbeschränkungen, Pattern-Facetten und zwei Jahrzehnten Tooling, das ein Dokument validieren und exakt melden kann, welches Element welche Regel gebrochen hat. JSON Schema verfolgt dasselbe Ziel in anderer Gestalt – es ist ausdrucksstark, unterstützt konditionale Logik und ist zur De-facto-Vertragssprache moderner APIs geworden –, aber seine lange Entwurfsgeschichte bedeutet, dass das Tooling stärker darin variiert, was es akzeptiert. Beide Ökosysteme können streng sein; das von XML ist schlicht älter.

Namespaces sind XMLs andere dauerhafte Stärke. Eine XHTML-Seite kann SVG und MathML einbetten, ohne dass Schlüssel kollidieren, weil jedes Vokabular seine eigene URI trägt. JSON hat keinen gleichwertigen Mechanismus – Namenskollisionen werden per Konvention vermieden oder durch geschichtete Entwürfe wie JSON-LD, die Kontext explizit mitbringen.

Größe, Streaming und wann sich welches eignet

Bei denselben Daten sind XML-Payloads meist größer: Allein die schließenden Tags verdoppeln das Element-Markup ungefähr, attributlastige Stile fügen mehr hinzu. Beide Formate komprimieren mit gzip gut – XMLs Redundanz ist bestens komprimierbar –, aber der Grund-Overhead schließt sich selten ganz. Beim Streaming läuft XMLs Parser-Ökosystem tiefer: SAX- und StAX-Push-Parser wurden für Dokumente entworfen, die zu groß für den Speicher sind, und jede Plattform bringt einen mit. JSON-Streaming-Parser existieren und sind exzellent, aber das Parsen des ganzen Dokuments bleibt der übliche Standard.

Nehmen Sie JSON für alles, was zwei Programme austauschen: Web- und Mobile-APIs, strukturierte Logs, Payloads von Dienst zu Dienst. Nehmen Sie XML, wenn eine Spezifikation es vorschreibt – SOAP-Stacks, Veröffentlichungs-Pipelines, Office-Formate, viele Gesundheits- und Finanzstandards – oder wenn Sie XSD-Validierung und Namespaces auf der Leitung brauchen. Die Empfehlung kippt sauber: JSON, das in eine Dokument-Pipeline hineinleckt, will meist XML sein, und eine API aus der SOAP-Ära, die sauberes JSON ausliefert, ist ein Migrationsgewinn, kein Verrat.