XML ist nicht tot (leider) – Wandle es in JSON um wie ein Erwachsener

Sie haben REST gelernt. Sie haben JSON akzeptiert. Sie dachten, die XML-Era sei vorbei, wie Flash oder IE6 – etwas, das Sie junioren Entwicklern wie ein Campfire-Geschicht erzählen würden. Dann überreichte Ihr neuer Kunde Ihnen API-Zugangsdaten für ihre Bankintegration, und da stand es: eine 400-Zeilen-SOAP-Enveloppe, die sich Ihnen gegenüber befand.

Willkommen zurück zu XML. Es ist nie verschwunden.

Warum XML noch überall präsent ist

Für viele Entwickler, die moderne Apps bauen, fühlt sich XML an wie ein Relikt. Doch in der Realität – besonders in Unternehmenssoftware, Banken, Gesundheitswesen und Regierungsanwendungen – ist XML eine absolut belastbare Infrastruktur. Hier werden Sie es begegnen:

• SOAP-Webdienste – Noch immer das Standardformat für Finanzinstitute, Versicherungssysteme und große ERP-Systeme. Ihre Fintech-Integration läuft wahrscheinlich über eines davon.
• Bank-APIs – ISO 20022, SWIFT-Nachrichten und viele Kernbank-APIs kommunizieren in XML. Es gibt keine REST-Option.
• Regierungsdaten – HMRC, die IRS und die meisten Regierungsportale akzeptieren oder liefern XML. Das wird sich bald nicht ändern.
• Unternehmensmittlere – SAP, Oracle und alte ESB-Systeme sprechen nativ XML. Wenn Sie mit etwas unternehmensstufen-qualifiziert integrieren, werden Sie wahrscheinlich XML begegnen.
• RSS- und Atom-Feeds – Noch immer XML. Viele Inhaltspipelines, Nachrichtenaggregatoren und Überwachungstools basieren darauf.

Die unangenehme Wahrheit: XML verschwindet nicht, weil die darauf aufgebauten Systeme nicht verschwinden. Die Erneuerung eines Bankkernsystems ist kein Sprint-Ticket. Also passen Sie sich an.

XML vs JSON: Die strukturellen Unterschiede, die Sie tatsächlich stören

Bevor Sie beginnen, umzustellen, hilft es, zu verstehen, warum die Umwandlung von XML in JSON nicht nur eine Formatwechsel ist. Die beiden Formate modellieren Daten unterschiedlich, und diese Unterschiede erzeugen echte Probleme.

Seitensweise: Die gleiche Daten in beiden Formaten

Nehmen Sie einen einfachen Kundenbestellvorgang. Hier ist er in XML:

<order id="ORD-1042" currency="GBP">
  <customer>
    <name>Alice Martin</name>
    <email>alice@example.com</email>
  </customer>
  <items>
    <item sku="PRD-001">
      <description>Wireless Keyboard</description>
      <quantity>1</quantity>
      <price>49.99</price>
    </item>
    <item sku="PRD-007">
      <description>USB-C Hub</description>
      <quantity>2</quantity>
      <price>29.99</price>
    </item>
  </items>
</order>

Und hier ist die äquivalente Version in JSON:

{
  "order": {
    "@id": "ORD-1042",
    "@currency": "GBP",
    "customer": {
      "name": "Alice Martin",
      "email": "alice@example.com"
    },
    "items": {
      "item": [
        {
          "@sku": "PRD-001",
          "description": "Wireless Keyboard",
          "quantity": "1",
          "price": "49.99"
        },
        {
          "@sku": "PRD-007",
          "description": "USB-C Hub",
          "quantity": "2",
          "price": "29.99"
        }
      ]
    }
  }
}

Sie können bereits die strukturellen Störpunkte erkennen. Lassen Sie uns sie durchgehen.

Attribute vs Schlüssel

XML-Elemente können Attribute (id="ORD-1042") neben Kindelementen und Textinhalt tragen. JSON hat keine Konzept von Attributen – alles ist ein Schlüssel-Wert-Paar. Die gängigste Konvention ist, Attribute mit @ beim Umwandeln vorzuführen, was Ihnen "@id": "ORD-1042"gibt. Einige Parser verwenden $ oder flachen sie komplett. Die Konvention ist wichtig, weil Ihr konsumierendes Code wissen muss, welchen Vorgang er erwarten kann.

Arrays vs wiederholte Elemente

Dieses Problem belastet Entwickler ständig. In JSON ist ein Array explizit: [...]. In XML gibt es keine solche Unterscheidung – wiederholte gleichartige Elemente sind implizit eine Liste. Ein Parser, der ein <item> Element sieht, gibt ein Objekt zurück. Zwei <item> Elemente? Er gibt ein Array zurück. Ihr Code bricht, wenn die API ein einzelnes Ergebnis zurückgibt.

Die Lösung ist, Arrays für bekannte Listenfelder zu erzwingen, oder eine Bibliothek zu verwenden, die Typinformationen beibehält. Wenn Sie einen einzelnen Datensatz konvertieren, überprüfen Sie, ob ein Feld, das wie ein einzelnes Objekt aussieht, in Produktionsdaten manchmal eine Liste ist.

Textknoten und gemischte Inhalte

XML-Elemente können sowohl Textinhalt als auch Kindelemente gleichzeitig enthalten (gemischte Inhalte). JSON kann dies nicht sauber darstellen. Parser behandeln es unterschiedlich – einige verwenden einen #text Schlüssel, andere verwenden _, andere lassen die gemischten Inhalte einfach weg. Wenn Sie XML mit gemischten Inhalten konvertieren, überprüfen Sie das Ergebnis manuell.

Namespaces

SOAP-Antworten sind voll von XML-Namensräumen: <ns2:getOrderResponse xmlns:ns2="http://...">. Abhängig von Ihrem Parser werden diese entweder entfernt, zusammengefasst in den Schlüsselname (ns2:getOrderResponse) oder auf eine URI abgebildet. Meistens wollen Sie sie entfernt, aber wenn zwei Namespaces denselben Elementnamen teilen, verlieren Sie die Unterscheidung. Wissen Sie, worauf Sie sich verlassen können, bevor Sie annehmen, dass das Ergebnis sauber ist.

Der schnelle Weg: Konvertieren Sie XML online, ohne einen Parser zu schreiben

Wenn Sie eine API-Antwort debuggen, eine unbekannte XML-Schema erkunden oder eine einmalige Konvertierung durchführen, ist das Schreiben eines Parsers übertrieben. Verwenden Sie das Converter von XML zu JSON — fügen Sie Ihr XML ein, erhalten Sie sofort sauberes JSON und überprüfen Sie die Struktur, bevor Sie Code schreiben.

Es behandelt Attribute (mit @ Konvention), verschachtete Elemente, wiederholte Elemente als Arrays und behält den Textinhalt bei – was die meisten realen API-Payloads abdeckt. Nützlich, um schnell zu verstehen, wie eine SOAP-Antwort tatsächlich aussieht, sobald die Hülle auf die Daten reduziert wurde.

Programmatische Konvertierung: Was Sie in der Produktion verwenden sollten

Für Produktionscode, der mit XML-APIs integriert wird, wollen Sie eine richtige Bibliothek anstatt ein handgeschriebenes Parser. Hier sind die Standardoptionen je Sprache:

JavaScript / Node.js

import { XMLParser } from 'fast-xml-parser';

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: '@',
  isArray: (name) => ['item', 'product', 'order'].includes(name),
});

const result = parser.parse(xmlString);

fast-xml-parser ist die beste Wahl für Node.js. Verwenden Sie isArray um die Arraybehandlung für bekannte Listenfelder zu erzwingen – dies verhindert das bekannte Problem, dass ein einzelnes Element zu einem Array wird, das in der Produktion schließlich auftritt.

Python

import xmltodict

with open('response.xml') as f:
    data = xmltodict.parse(f.read())

import json
print(json.dumps(data, indent=2))

xmltodict ist die Standardwahl in Python. Es verwendet die @ Konvention für Attribute und #text für Textknoten. Beachten Sie, dass es ein OrderedDictzurückgibt, das gut mit json.dumps.

PHP

$xml = simplexml_load_string($xmlString);
$json = json_encode($xml);
$data = json_decode($json, true);

serialisiert wird. simplexml_load_string + json_encode PHPs DOMDocument ist der schnelle Weg, aber es behandelt Attribute unkonsequent und kann Daten in Randfällen verlieren. Für Produktionsarbeit mit SOAP-Antworten, betrachten Sie LIBXML_NOBLANKS mit

oder eine spezielle Bibliothek.

• Zahlen werden als Strings dargestellt. XML hat keine numerischen Typen – alles ist Text. Ihr Preisfeld wird "49.99"sein, nicht 49.99. Konvertieren Sie es explizit nach der Umwandlung.
• Boolesche Werte bleiben als Strings. <active>true</active> wird zu "active": "true". Prüfen Sie, bevor Sie sie in Bedingungen verwenden.
• Leere Elemente werden null oder leere Objekte. <middleName/> möglicherweise zu null, "", oder {} abhängig von der Bibliothek. Testen Sie den Randfall.
• CDATA-Bereiche werden möglicherweise nicht erhalten. Wenn die API HTML-Inhalte mit CDATA ausgibt, überprüfen Sie, ob Ihre Bibliothek sie behandelt und nicht den Inhalt schlicht weglässt.
• Die Reihenfolge ist nicht garantiert. Die Reihenfolge von XML-Elementen kann in bestimmten Schemata bedeutend sein; die Reihenfolge von JSON-Objekt-Schlüsseln ist es nicht. Wenn die Reihenfolge für das konsumierende System wichtig ist, behandeln Sie sie explizit.

Arbeiten mit SOAP speziell

SOAP fügt eine weitere Schicht auf XML hinzu: Jede Antwort ist in einem <Envelope> mit einem <Body>, oft mit Namespace-Declarations und einem <Header> Block. Bevor Sie es in JSON konvertieren, möchten Sie normalerweise nur den Körperinhalt extrahieren.

In Python mit zeep (dem SOAP-Klient) erhalten Sie Python-Objekte direkt und müssen sich nicht selbst mit XML auseinandersetzen. In Node.js, soap und strong-soap macht das gleiche. Wenn Sie einen SOAP-Endpunkt direkt mit fetch oder axiosaufrufen, müssen Sie den Hülle manuell entfernen, bevor Sie Ihren XML-zu-JSON-Konverter starten.

Für schnelle Inspektion von SOAP-Antworten ist das Converter von XML zu JSON nützlich – fügen Sie die vollständige Hülle ein, sehen Sie die vollständige Struktur und bestimmen Sie, welchen Pfad Sie tatsächlich benötigen.

Akzeptieren Sie die Realität und gehen Sie weiter

Es gibt eine bestimmte Art von Leid, die entsteht, wenn man merkt, dass Ihr Greenfield-Projekt mit einer SOAP-API aus dem Jahr 2003 integrieren muss. Lassen Sie sich das fühlen, dann gehen Sie weiter. XML ist ein gelöstes Problem – die Parsers sind reif, die Umwandlungs-Tools existieren und die Probleme sind gut dokumentiert. Sie sind nicht der erste Entwickler, der einem 400-Zeilen-Enveloppe gegenübersteht.

Verwenden Sie die richtige Bibliothek für Ihre Sprache, behandeln Sie die Typumwandlung explizit, erzwingen Sie Arrays für bekannte Listenfelder und testen Sie mit echten Payloads anstatt mit den idealisierten Beispielen in den API-Dokumenten. Die Dokumente zeigen Ihnen ein Element; die Produktion sendet Ihnen fünfzig.

Und für die explorativen Arbeiten – das Verständnis eines unbekannten XML-Schemas, die Validierung einer Konvertierung vor dem Schreiben von Code – halten Sie das Converter von XML zu JSON im Bookmark. Es ist schneller als jedes Mal ein Skript aufzurufen, wenn Sie ein Payload inspizieren müssen.

Das könnte Ihnen auch gefallen