Ein tiefer Blick auf JSON vs. XML, Teil 1: Die Geschichte jedes Standards

Vom Desktop über das Web bis hin zu Mobilgeräten verlassen sich fast alle Computeranwendungen, die wir heute verwenden, auf einen von zwei Hauptnachrichtenstandards: JSON und XML. Heute ist JSON das am weitesten verbreitete Format, aber es hat XML erst in den letzten fünf Jahren überholt. Eine schnelle Online-Suche nach „JSON vs. XML“ bringt unzählige Artikel und Blog-Beiträge, die die beiden Standards vergleichen, und führt zu einer zunehmend wachsenden Neigung, die die Einfachheit von JSON lobt und die Ausführlichkeit von XML kritisiert. Zahlreiche Artikel beharren darauf, dass JSON XML aufgrund seiner knappen Semantik überlegen sei und diskreditieren XML als ineffizienten und verwirrenden Standard der Vergangenheit. Auf den ersten Blick scheint JSON am beliebtesten zu sein – ist JSON also einfach besser als XML? Der Kampf „JSON vs. XML“ mag an der Oberfläche um JSON ausgetragen werden, aber in der Tiefe steckt mehr dahinter, als man auf den ersten Blick sieht.

In Teil 1 dieses Artikels werden wir:

1. Werfen Sie einen genaueren Blick auf die Geschichte des Webs, um den ursprünglichen Zweck von XML und JSON aufzudecken.
2. Betrachten Sie die Entwicklung von Softwaretrends in den letzten Jahren, um festzustellen, warum JSON populärer als XML wurde.

Die Geschichte von JSON und XML

Um den Grund für die Popularität von JSON gegenüber XML aufzudecken, untersuchen wir die Geschichte des Webs und wie seine Entwicklung von Web 1.0 zu Web 2.0 die Entwicklungstrends beeinflusst hat.

Das Web 1.0: HTML

Die frühen 1990er Jahre waren die Geburtsstunde von Web 1.0. HTML wurde 1991 eingeführt und von Universitäten, Unternehmen und Regierungsorganisationen weitgehend als Sprache des Internets übernommen. HTML kam von SGML oder „Standard Generalized Markup Language“, das in den 1970er Jahren von IBM erfunden wurde. Neben der Massenakzeptanz wurde HTML auch massenhaft angepasst – Erweiterungen wurden eingebettet, um Multimedia, Animationen, Online-Anwendungen, E-Commerce und mehr zu unterstützen. Als Abkömmling von SGML fehlte HTML eine strenge Spezifikation, um Unternehmen daran zu hindern, es frei zu erweitern, um Anforderungen zu erfüllen, die über das ursprüngliche Konzept hinausgingen. Der Wettbewerb um den beliebtesten Webbrowser zwischen Netscape und Microsoft brachte schnelle Fortschritte, führte aber auch zu einer unaufhaltsamen Fragmentierung des Standards. Der harte Wettbewerb führte zu einer „Divergenz-Katastrophe“, da die Erweiterung von HTML durch die beiden Unternehmen dazu führte, dass die Browser ihre eigenen einzigartigen HTML-Versionen unterstützten. Diese Divergenzkatastrophe wurde zu einem großen Problem für Webanwendungen, da Entwickler Schwierigkeiten hatten, interoperablen Code für die Browser zu schreiben.

Das Web 1.1: XML + HTML = XHTML

In den späten 1990er Jahren entwickelte eine Gruppe von Leuten – darunter Jon Bosak, Tim Bray, James Clark und andere – XML: die „eXtensible Markup Language“. Wie SGML ist XML selbst keine Auszeichnungssprache, sondern eine Spezifikation zur Definition von Auszeichnungssprachen. XML war eine Weiterentwicklung von SGML – entwickelt, um ein Mittel bereitzustellen, um strukturierte Inhalte zu definieren und durchzusetzen. Die XML-Sprache, die als „der heilige Gral der Informatik“ ¹ gilt, bemühte sich, „das Problem des universellen Datenaustauschs zwischen unterschiedlichen Systemen zu lösen“ (Dr. Charles Goldfarb) ² . Anstelle der fortschreitenden Fragmentierung von HTML wurde das World Wide Web Committee (W3C) gegründet, um die Kompatibilität und Einigung in der Branche bei der Annahme neuer Standards für das World Wide Web zu fördern. ³ Das W3C machte sich daran, HTML in eine XML-Anwendung umzugestalten, mit dem Ergebnis XHTML.

XHTML war eine große Initiative, die die Aufmerksamkeit auf XML lenkte, aber es ist nur ein kleiner Teil dessen, worum es bei XML geht.

XML bot der Industrie eine Möglichkeit, benutzerdefinierte Auszeichnungssprachen mit strenger Semantik für jede Anwendung zu spezifizieren. Mit dem Schlüsselwort „strikte Semantik“ definierte XML einen Standard, der die Integrität von Daten in jedem XML-Dokument und jeder XML-Untersprache behaupten konnte. Für Softwareunternehmen, die verteilte Unternehmensanwendungen entwickeln, die mit unterschiedlichen Systemen verbunden sind, war eine Auszeichnungssprache, die die Integrität ihrer Daten bestätigen konnte, von Bedeutung. Durch die Definition strukturierter Inhalte mit XML nutzten Unternehmen die Funktionen dieser Technologie, um mit jeder Plattform zusammenzuarbeiten, die Datenintegrität bei jedem Datenaustausch durchzusetzen und das Softwarerisiko ihrer Systeme systematisch zu reduzieren. Für die Industrie bot XML eine Technologie zum Speichern, Kommunizieren und Validieren jeglicher Art von Daten in einer Form, die Anwendungen auf jeder Plattform leicht lesen und verarbeiten können. Für HTML versprach XML, die „Divergenz-Katastrophe“ zu lösen.

Java und .NET

In den frühen 2000er Jahren wurde das Web von zwei Unternehmen regiert: Sun und Microsoft. Zu dieser Zeit war die Landschaft der Programmiersprachen stark serverseitig geneigt. Die übliche Architektur für Webanwendungen stützte sich auf Server, die HTML-Seiten im Back-End rendern, um sie an den Browser zu liefern. Dieser Ansatz hob Back-End-Technologien hervor, die wiederum die führenden Back-End-Plattformen populär machten: Java und C#.NET. Java wurde von Sun Microsystems entwickelt und führte die neue Generation objektorientierter Programmiersprachen an, die das architekturübergreifende Problem mit seinem neuartigen „Write Once Run Anywhere“-Ansatz ⁴ löste. Microsoft folgte mit .NET, C# und der Common Language Runtime (CLR) und richtete sein Augenmerk auf XML als bevorzugten Ansatz zur Lösung des Rätsels der Dateninteroperabilität. Microsoft wurde zum größten Verfechter von XML, wobei das Unternehmen XML als integralen Bestandteil seiner prominenten .NET-Initiative wählte. Als „Plattform für XML-Webdienste“ beworben, wurden ⁵ .NET-Anwendungen so konzipiert, dass sie XML für die Kommunikation mit anderen Plattformen verwenden. Als Datenaustauschstandard von Microsoft ausgewählt, wurde XML in seine Flaggschiff-Serverprodukte wie SQL Server und Exchange integriert.

Das Web 1.2: AJAX

Die Bereitstellung vorgerenderter HTML-Seiten an den Browser war nicht skalierbar, und das Web benötigte eine Alternative. Mit jeder Benutzeraktion, die das Laden einer neuen Seite vom Server erforderte, wurden die Prozesslast und der Bandbreitenverbrauch zu einem Problem, da das Internet immer mehr Menschen anschwoll.

Netscape und Microsoft versuchten, dieses Problem mit asynchroner Inhaltsübermittlung anzugehen: ActiveX und JavaScript. 1998 entwickelte das Microsoft Outlook Web Access-Team das Konzept hinter ActiveX ⁶ , das später von Mozilla, Safari, Opera und anderen Browsern in JavaScript als XMLHttpRequest Objekt implementiert wurde.

AJAX wurde aus Microsofts ActiveX und Netscapes JavaScript geboren.

Der Begriff AJAX – kurz für „Asynchronous JavaScript and XML“ – steht mittlerweile für ein breites Spektrum an Webtechnologien, mit denen sich Webanwendungen realisieren lassen, die im Hintergrund mit Servern kommunizieren, ohne dass eine Seite neu geladen werden muss. In dem Artikel, der den Begriff AJAX prägte, ^{7 8} skizzierte Jesse James Garrett die wichtigsten Konzepte:

1. HTML (oder XHTML) und CSS für die Präsentation.
2. Das Document Object Model (DOM) zur dynamischen Anzeige von und Interaktion mit Daten.
3. XML für den Datenaustausch und XSLT für deren Manipulation.
4. Das XMLHttpRequest Objekt für die asynchrone Kommunikation.
5. JavaScript, um diese Technologien zusammenzubringen.

Da die asynchrone Bereitstellung von Inhalten erwiesenermaßen die Serverlast reduziert und beträchtliche Bandbreite einspart, war AJAX ein Wendepunkt. Die Einführung von XMLHttpRequest in die Browser ermöglichte es Entwicklern, komplexere Logik im Frontend zu implementieren. Google hat standardkonformes, browserübergreifendes AJAX mit Gmail im Jahr 2004 und Google Maps im Jahr 2005 umfassend eingeführt. ⁹ Und im Oktober 2004 gehörte die öffentliche Betaversion von Kayak.com zu den ersten groß angelegten eCommerce-Einsätzen von AJAX. ¹⁰

Das Web 2.0: Single-Page-Anwendungen

Die Einführung von AJAX als skalierbare Architektur für Webanwendungen führte zum Beginn von Web 2.0: der Single-Page Application (SPA). ¹¹ Anstatt die gesamte Seite für jede Benutzerinteraktion neu zu laden, schreiben SPAs die aktuelle Seite im Browser dynamisch neu. Neben einer erheblichen Reduzierung der Serverlast und des Bandbreitenverbrauchs ermöglichte der SPA-Ansatz, dass Webanwendungen aufgrund der nahtlosen und ununterbrochenen Erfahrung während der Benutzerinteraktion Desktopanwendungen ähneln.

Im April 2002 schrieb Stuart Morris eine der ersten SPAs unter slashdotslash.com ¹² , und später im selben Jahr beschrieben Lucas Birdeau, Kevin Hakman, Michael Peachey und Evan Yeh im US-Patent 8,136,109 eine Single-Page-Anwendungsimplementierung. ¹³ Das Patent beschrieb Webbrowser, die JavaScript verwenden, um die Benutzeroberfläche anzuzeigen, Anwendungslogik auszuführen und mit einem Webserver zu kommunizieren.

Googles Gmail, Google Maps und die öffentliche Betaversion von Kayak haben eine neue Ära der Entwicklung von Webanwendungen ausgelöst. Mit AJAX aktivierte Browser versetzten Entwickler in die Lage, umfangreiche Anwendungen für das Web zu schreiben. Die einfache Semantik von JavaScript machte die Anwendungsentwicklung für Programmierer jeden Kalibers möglich. Die Eintrittsbarriere in die Softwareentwicklung wurde stark reduziert, und einzelne Entwickler auf der ganzen Welt begannen, ihre eigenen Bibliotheken und Frameworks beizusteuern. Beliebte Bibliotheken wie jQuery, die das AJAX-Verhalten über Browser verschiedener Hersteller hinweg normalisieren, haben die AJAX-Revolution weiter vorangetrieben.

Der Aufstieg von JSON

Im April 2001 verschickten Douglas Crockford und Chip Morningstar die erste JSON-Nachricht von einem Computer in der Garage von Morningstar in der Bay Area. Crockford und Morningstar versuchten, AJAX-Anwendungen zu erstellen, lange bevor der Begriff „AJAX“ geprägt wurde, aber die Browserunterstützung für das, was sie zu erreichen versuchten, war nicht gut. Sie wollten Daten nach dem Laden der Seite an ihre Anwendung übergeben, hatten aber keine Möglichkeit gefunden, dies in allen Browsern zu ermöglichen.

Im Jahr 2001 begann die Entwicklung von AJAX gerade, und es gab noch keine interoperable Form des XMLHttpRequest -Objekts in Internet Explorer 5 und Netscape 4. Daher verwendeten Crockford und Morningstar einen anderen Ansatz, der in beiden Browsern funktionierte.

Die erste JSON-Nachricht sah so aus:

 <html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session," do: "test," text: "Hello world" } ) </script></head></html>

Diese Nachricht ist eigentlich ein HTML-Dokument, das etwas JavaScript enthält, und nur ein kleiner Teil der Nachricht ähnelt JSON, wie wir es heute kennen. Crockford und Morningstar konnten Daten asynchron laden, indem sie einen <iframe> auf eine URL verwiesen, die ein HTML-Dokument wie das obige zurückgeben würde. Wenn die Antwort empfangen wurde, wurde das JavaScript im HTML ausgeführt, und durch Umgehung des Browserschutzes, der verhindert, dass Unterfenster auf das übergeordnete Fenster zugreifen, wurde das Objektliteral an den Hauptrahmen der Anwendung zurückgegeben. Diese Frame-basierte Technik, manchmal auch als „Hidden-Frame-Technik“ bezeichnet, wurde Ende der 90er Jahre vor der weit verbreiteten Implementierung von XMLHttpRequest häufig verwendet. ¹⁴

Dieser Ansatz sprach Entwickler an, da er Interoperabilität über alle Browser hinweg bot. Da es sich bei der Nachricht nur um JavaScript handelt, ist keinerlei spezielles Parsing erforderlich. Die Idee, JavaScript auf diese Weise zu verwenden, war so einfach, dass Crockford selbst sagte, dass er nicht der Erste war, der dies getan hat – er behauptet, dass jemand bei Netscape bereits 1996 ^JavaScript verwendet hat, um Informationen zu übermitteln

Crockford und Morningstar erkannten, dass sie etwas hatten, das in allen möglichen Anwendungen eingesetzt werden konnte. Sie nannten ihr Format JSON, was die Abkürzung für „JavaScript Object Notation“ ist. Sie begannen, es Kunden vorzustellen, stellten jedoch bald fest, dass viele nicht bereit waren, eine neuartige Technologie zu riskieren, für die es keine offizielle Spezifikation gab. Also beschloss Crockford, dass er einen schreiben würde. 2002 kaufte Crockford die Domain JSON.org und stellte die JSON-Grammatik und eine Referenzimplementierung eines Parsers zur Verfügung. Die Website ist immer noch aktiv, obwohl sie jetzt einen prominenten Link zum 2013 ^{ratifizierten} JSON-ECMA-Standard enthält. Der Ursprung von JSON ist eindeutig mit JavaScript verbunden, aber es zeigte sich, dass JSON gut geeignet war, Daten zwischen beliebigen Sprachen auszutauschen.

JSON in AJAX

Im Jahr 2005 prägte Jesse James Garrett den Begriff „AJAX“ in einem Blogbeitrag, in dem er betonte, dass AJAX nicht irgendeine neue Technologie sei, sondern „mehrere Technologien, von denen jede für sich blüht und auf neue, leistungsstarke Weise zusammenkommt“. ¹⁶ Sein Blogbeitrag beschrieb weiter, wie Entwickler JavaScript und XMLHttpRequest nutzen könnten, um neue Arten von Anwendungen zu erstellen, die reaktionsfähiger und zustandsorientierter seien als die typische Webseite. Er verwies auf Gmail, Google Maps und Flickr als Beispiele für Websites, die AJAX-Techniken verwenden. Obwohl „X“ in „AJAX“ für XML stand, wies Garrett auf JSON als durchaus akzeptable Alternative hin. Er schrieb, dass „XML das am weitesten entwickelte Mittel ist, um Daten in und aus einem AJAX-Client zu bekommen, aber es gibt keinen Grund, warum Sie nicht die gleichen Effekte mit einer Technologie wie JavaScript Object Notation oder ähnlichen Mitteln zur Strukturierung von Daten erzielen könnten.“ ¹⁷

JavaScript und JSON sollten eindeutig zusammengehören. Die Semantik von JSON wird direkt auf JavaScript abgebildet, was es zum nativen Datenaustauschformat für die Sprache macht. Entwickler stellten schnell fest, dass JSON in JavaScript einfacher zu handhaben war, und viele zogen es XML vor.

Als JSON die Aufmerksamkeit der Blogosphäre auf sich zog, hatte die Verbreitung von JSON begonnen.

Warum JSON populärer wurde als XML

JSON ist das native Format für Daten in JavaScript-Anwendungen. Mit der Popularisierung von JavaScript im letzten Jahrzehnt wurden mehr JSON-Nachrichten erstellt als jedes andere Datenformat. Das Schreiben von Anwendungen in JavaScript erfordert fast die Verwendung von JSON für den Datenaustausch. Andere Formate sind möglich, erfordern aber mehr Aufwand als bei JSON. Da JavaScript für die Anwendungsentwicklung immer beliebter wurde, folgte JSON als benutzerfreundliches und nativ integriertes Datenaustauschformat dicht hinterher.

In der Blogosphäre wurden mehr Artikel, Beispiele und Tutorials über JavaScript (und damit JSON) geschrieben als über jede andere Programmierplattform.

Die Geschichte und der Evolutionspfad des Webs haben eine bedeutende Rolle bei der Popularisierung von JSON gespielt. Laut Stack Overflow werden mittlerweile mehr Fragen zu JSON gestellt als zu anderen Datenaustauschformaten. ¹⁸

Laut Google Trends wird ein ähnliches Profil gesehen, das das Suchinteresse für JSON und XML vergleicht. ¹⁹

Bedeutet die Verbreitung von JavaScript, dass JSON besser ist als XML?

Entwicklergemeinschaften bestehen darauf, dass JSON aufgrund seines prägnanten deklarativen Umfangs und seiner einfachen Semantik beliebter wurde als XML. Douglas Crockford selbst fasst einige der Vorteile von JSON auf JSON.org zusammen: „JSON ist sowohl für Menschen als auch für Maschinen einfacher zu verstehen, da seine Syntax minimal und seine Struktur vorhersehbar ist.“ ²⁰ Andere XML-Kritiker haben sich auf die Ausführlichkeit von XML als „Spitzenklammer-Steuer“ konzentriert. ²¹ Das XML-Format erfordert, dass jedem öffnenden Tag ein schließendes Tag zugeordnet wird, was zu redundanten Informationen führt, die ein XML-Dokument deutlich größer machen können als ein entsprechendes JSON-Dokument, wenn es unkomprimiert ist. Und, was vielleicht noch wichtiger ist, sagen Entwickler: „Es macht ein XML-Dokument auch schwerer lesbar.“ ²²

JSON wurde aufgrund seiner Einfachheit und knappen Semantik gerne gelobt, und XML wurde aufgrund seiner Ausführlichkeit und scheinbar übermäßigen Komplexität als veralteter Standard der Vergangenheit bezeichnet. Viele Artikel und Blog-Beiträge bieten eine begrenzte Perspektive beim Vergleich von JSON mit XML, was die Leser zu der Annahme verleitet, dass JSON ein Ersatz für XML ist. Das ist nicht der Fall!

Die begrenzte Perspektive, die Artikel und Blogbeiträge bieten, hat dazu geführt, dass Leser XML als obsolet abtun, wodurch viele leistungsstarke Funktionen nicht kennen, die ihnen helfen können, die Architektur und Widerstandsfähigkeit ihrer Software gegenüber Änderungen zu verbessern und Softwarerisiken systematisch zu reduzieren.

JSON ist beliebter als XML, da JavaScript die heute am weitesten verbreitete Sprache ist. Mit dem Einfluss von JavaScript auf Softwaretrends im letzten Jahrzehnt erhält JSON weiterhin zunehmend mehr Aufmerksamkeit als jedes andere Datenaustauschformat. Die Blogosphäre wiederholt schnell, dass „JSON besser als XML ist“, aber meistens bleiben diese Aussagen ungerechtfertigt oder werden mit vereinfachenden Vergleichen in Bezug auf Semantik und Ausführlichkeit untermauert. Ist also einer der Standards besser als der andere? Die Antwort auf diese Frage kann nur aus einer tieferen Bewertung jedes Standards kommen.

Fazit

Von 1990 bis heute hat das Web einen langen Weg zurückgelegt. Die Browserkriege zwischen Netscape und Microsoft führten zu einer Divergenzkatastrophe von HTML, und es musste eine Lösung gefunden werden, um das Web zu retten. XML wurde erfunden, um XHTML zu formalisieren, und lieferte eine heilige Gral-Lösung für die Datenverarbeitung als Ganzes. Von der Wiedergabe vollständiger HTML-Seiten durch Back-End-Server bis hin zu AJAX und SPAs haben Trends in der Webarchitektur und Browserentwicklung den Fokus auf JavaScript gelenkt und Entwickler weltweit in Richtung JSON gelenkt.

Die Popularität von JSON korreliert mit der von JavaScript. Mit seiner Benutzerfreundlichkeit und kurzen Lernkurve hat JavaScript mehr neue Entwickler dazu gebracht, Software zu schreiben, als jede andere Sprache. Mit der nativen Integration von JSON in die beliebteste Entwicklungsplattform ist es nicht verwunderlich, dass mehr Fragen zu JSON auf Stack Overflow gestellt werden als zu jedem anderen Datenaustauschformat.

Mit Softwaretrends in den letzten Jahren, die mehr JavaScript-Entwickler in die Branche brachten, hat JSON den Titel des „beliebtesten Datenaustauschformats“ erhalten.

Oberflächlich betrachtet geht der Kampf „JSON vs. XML“ an JSON, aber in der Tiefe steckt mehr dahinter, als man auf den ersten Blick sieht.

In Teil 2 dieses Artikels werden wir uns die technischen Stärken und Schwächen von JSON und XML genauer ansehen und die Eignung jedes Standards für gängige Anwendungen und das Unternehmen bewerten. Ein genauerer Blick auf den „Datenaustausch“ zeigt die Breite seines Einflusses auf das Softwarerisiko der Anwendung insgesamt. Ein tieferes Verständnis der grundlegenden Unterschiede zwischen JSON und XML wird es Entwicklern ermöglichen, das Softwarerisiko jedes Standards in Bezug auf die Anforderungen ihres Projekts besser einzuschätzen – um Entwickler in die Lage zu versetzen, Software zu entwickeln, die stabiler und widerstandsfähiger gegen Fehler und Zukunft ist Unbekannte.

Eine interessante Eigenart der JSON-Spezifikation ist übrigens, dass Sie JavaScript-Objekte mit bidirektionalen Beziehungen, bei denen untergeordnete Eigenschaften auf übergeordnete Eigenschaften verweisen, nicht in JSON konvertieren können. Dies würde zu einem Uncaught TypeError: Converting circular structure to JSON -Fehler führen. Einen Trick zur Umgehung dieser Einschränkung finden Sie unter Unterstützung für bidirektionale Beziehungen in JSON .

Verweise

1. Das Internet: Eine historische Enzyklopädie. Chronologie, Band 3, p. 130 (ABC CLIO, 2005)

2. Handbuch der Metadaten, Semantik und Ontologien, p. 109 (World Scientific, Dezember 2013)

3. WebDiy.org - World Wide Web Consortium (W3C) - Geschichte

4. „JavaSoft liefert Java 1.0 aus“ (Sun Microsystems, Januar 1996)

5. Räumliche Ermöglichung des Internets der nächsten Generation (David Engen, Januar 2002)

6. Die Geschichte von XMLHTTP (AlexHopmann.com, Januar 2007)

7. Beginnend mit Ajax – Seite 2 (Wiley Publishing, März 2007)

8. Ajax: Ein neuer Ansatz für Webanwendungen (Jesse James Garrett, Februar 2005)

9. Eine kurze Geschichte von Ajax (Aaron Swartz, Dezember 2005)

10. „Was ist Kayak.com?“ (Corporate Backgrounder, Oktober 2008)

11. Inner-Browsing: Extending the Browsing Navigation Paradigm (Netscape, Mai 2003)

12. „Eine eigenständige Website mit DHTML“ (SlashDotSlash.com, Juli 2012)

13. Lieferung von Daten und Formatierungsinformationen, um eine Manipulation auf Clientseite zu ermöglichen (US Patent Bureau, April 2002)

14. "Was ist Ajax?" Professionelles Ajax, 2. Aufl. (Wiley, März 2007)

15. Douglas Crockford: The JSON Saga (Yahoo!, Juli 2009)

16. ECMA-Standard 404 (ECMA International, Dezember 2017)

17. Ajax: Ein neuer Ansatz für Webanwendungen (Jesse James Garrett, Februar 2005)

18. Stack Overflow-Trends (Stack Overflow, 2009-2019)

19. Google Trends (Google, 2004-2019)

20. JSON: Die fettfreie Alternative zu XML (Crockford, 2006)

21. XML: The Angle Bracket Tax (Coding Horror, Mai 2008)

22. XML nervt (WikiWikiWeb, 2016)