Artikel geschrieben im September 2017
JSON hat die Welt übernommen. Wenn heute zwei Anwendungen über das Internet miteinander kommunizieren, tun sie dies höchstwahrscheinlich mit JSON. Der Standard wird von allen Hauptakteuren akzeptiert: Von den zehn beliebtesten Web-APIs, die hauptsächlich von großen Unternehmen wie Google, Facebook und Twitter entwickelt werden, überträgt
nur eine API Daten in XML, nicht in JSON. Beispielsweise unterstützte Twitter XML bis 2013, als es eine neue Version der API exklusiv in JSON veröffentlichte. Unter anderen Entwicklern ist JSON ebenfalls beliebt: Laut Stack Overflow werden
mehr Fragen zu JSON gestellt als zu jedem anderen Datenaustauschformat .
XML lebt noch und wird häufig verwendet. Zum Beispiel in den Webformaten SVG, RSS und Atom. Wenn der Autor der Android-Anwendung erklären möchte, dass er die Erlaubnis des Benutzers benötigt, tut er dies in dem in XML geschriebenen Anwendungsmanifest. Und XML ist nicht die einzige JSON-Alternative: Einige Entwickler entscheiden sich für die YAML- oder Protokollpuffer von Google. Diese Formate sind jedoch bei weitem nicht so beliebt wie JSON, das mittlerweile fast zum De-facto-Standard für den Datenaustausch zwischen Programmen über das Internet geworden ist.
Die Dominanz von JSON ist erstaunlich, da bereits 2005 alle das Potenzial von „asynchronem JavaScript und XML“ anstelle von „asynchronem JavaScript und JSON“ diskutierten. Natürlich ist es wahrscheinlich, dass dies nichts über die relative Popularität der beiden Formate aussagt, nur AJAX schien eine attraktivere Abkürzung zu sein als AJAJ. Obwohl einige Leute bereits 2005 JSON anstelle von XML verwendeten (tatsächlich nur wenige), fragen Sie sich immer noch, wie XML so stark fallen könnte, dass ein Jahrzehnt später der Ausdruck „asynchrones JavaScript und XML“ ein ironisches Grinsen hervorruft. Was ist in diesem Jahrzehnt passiert? Wie hat JSON XML in vielen Anwendungen ersetzt? Und wer hat dieses Datenformat erfunden, von dem Ingenieure und Systeme auf der ganzen Welt heute abhängen?
Die Geburt von JSON
Die erste JSON-Nachricht wurde im April 2001 von einem Computer in einer Garage in der Nähe von San Francisco gesendet. Die Geschichte hat die Namen der an der Veranstaltung Beteiligten beibehalten: Douglas Crockford und Chip Morningstar, Mitbegründer des Technologieberatungsunternehmens State Software.
Diese beiden hatten AJAX-Anwendungen entwickelt, lange bevor der Begriff AJAX auftauchte. Die Anwendungsunterstützung in Browsern war jedoch nicht sehr gut. Sie wollten nach dem ersten Laden der Seite Daten in ihre Anwendung übertragen, fanden jedoch keinen Weg, der in allen Browsern funktioniert.
Es ist heute kaum zu glauben, aber Internet Explorer war 2001 der fortschrittlichste Browser. Seit 1999 unterstützt Internet Explorer 5 die frühe Form von XMLHttpRequest über ActiveX. Crockford und Morningstar konnten diese Technologie verwenden, um Daten in der Anwendung abzurufen, aber sie funktionierte in Netscape 4 nicht. Daher musste ich nach einem anderen Format suchen, das in beiden Browsern funktionierte.
Die erste JSON-Nachricht sah folgendermaßen aus:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html>
Nur ein kleiner Teil der Nachricht ähnelt JSON, wie wir es heute kennen. Die Nachricht selbst ist eigentlich ein HTML-Dokument mit ein paar Zeilen JavaScript. Der JSON-ähnliche Teil ist nur ein JavaScript-Literal für die Funktion
receive() .
Crockford und Morningstar haben beschlossen, den HTML-Frame zum Senden von Daten zu missbrauchen. Für einen Frame können Sie eine URL angeben, die ein HTML-Dokument ähnlich dem oben genannten zurückgibt. Wenn der HTML-Code empfangen wird, wird JavaScript gestartet und das Literal an die Anwendung zurückgegeben. Dies funktionierte unter der Bedingung, dass der Browserschutz sorgfältig umgangen wurde, um zu verhindern, dass das Kind auf das übergeordnete Fenster zugreift: Wie Sie sehen können, legen Crockford und Morningstar die Dokumentdomäne explizit fest. Diese Technik wird manchmal als versteckter Frame bezeichnet und wurde
häufig in den späten 90ern vor dem normalen XMLHttpRequest verwendet .
Was am ersten JSON-Beitrag überrascht, ist, dass es überhaupt nicht offensichtlich ist, dass dies die erste Verwendung eines neuen Datenformats ist. Es ist nur JavaScript! Tatsächlich ist die Idee, JavaScript so zu verwenden, so einfach, dass Crockford selbst glaubt, dass er nicht der erste war, der dies tat - er behauptet, dass jemand in Netscape 1996 JavaScript-Array-Literale verwendet hat, um Informationen zu übertragen. Das Posten in einfachem JavaScript erfordert keine spezielle Analyse. Alles wird vom JavaScript-Interpreter erledigt.
Tatsächlich hatte die erste JSON-Nachricht in der Historie Probleme mit dem Interpreter. JavaScript reserviert eine große Anzahl von Wörtern - 64 Wörter sind in ECMAScript 6 reserviert - und Crockford und Morningstar haben sie unabsichtlich in ihrer Nachricht verwendet: nämlich das reservierte Wort
do als Schlüssel. Da JavaScript so viele reservierte Wörter enthält, hat Crockford beschlossen, diese nicht zu vermeiden, sondern einfach alle JSON-Schlüssel zu zitieren. Der in Anführungszeichen gesetzte Schlüssel wird vom JavaScript-Interpreter als Zeichenfolge betrachtet, sodass Sie die reservierten Wörter sicher verwenden können. Aus diesem Grund werden JSON-Schlüssel immer noch in Anführungszeichen gesetzt.
Crockford und Morningstar erkannten, dass die neue Methode in allen Arten von Anwendungen eingesetzt werden kann. Sie wollten das JSML-Format (JavaScript Markup Language) aufrufen, aber es stellte sich heraus, dass die Abkürzung bereits mit der sogenannten Java Speech Markup Language beschäftigt war. Daher haben wir uns für die Javascript-Objektnotation entschieden, d. H. JSON. Sie begannen, ihren Kunden das Format anzubieten, aber es wurde schnell klar, dass sie nicht riskierten, eine unbekannte Technologie ohne offizielle Spezifikation zu verwenden. Also beschloss Crockford, es zu schreiben.
Im Jahr 2002 kaufte Crockford die Domain
JSON.org , veröffentlichte die JSON-Syntax und eine Beispielimplementierung des Parsers. Die Website funktioniert noch, obwohl sie jetzt einen Link zum 2013 verabschiedeten JSON ECMA-Standard enthält. Zusätzlich zum Start der Site hat Crockford praktisch nichts unternommen, um JSON zu bewerben, aber bald gab es Implementierungen des JSON-Parsers in einer Vielzahl von Programmiersprachen. Anfangs war JSON eindeutig mit JavaScript verbunden, aber dann wurde klar, dass es sich gut für den Datenaustausch zwischen beliebigen Sprachpaaren eignet.
Falscher AJAX
JSON hat 2005 einen großen Schub bekommen. Dann prägte ein Designer und Entwickler namens Jesse James Garrett in seinem
Artikel den Begriff AJAX. Er versuchte zu betonen, dass AJAX nicht nur eine neue Technologie ist, sondern "mehrere auf ihre Weise gute Technologien, die auf leistungsstarke neue Weise kombiniert werden". Garrett nannte AJAX einen neuen Ansatz für die Entwicklung von Webanwendungen. In einem Blogbeitrag beschrieb er, wie Entwickler JavaScript und XMLHttpRequest verwenden können, um interaktivere Anwendungen zu erstellen. Er nannte Google Mail und Flickr Beispiele für Websites, die auf AJAX-Methoden basieren.
Natürlich bedeutete "X" in AJAX XML. In nachfolgenden Fragen und Antworten nannte Garrett JSON eine absolut akzeptable Alternative. Er schrieb: "XML ist das funktionalste Datenaustausch-Tool für den AJAX-Client, aber der gleiche Effekt kann mit Javascript Object Notation oder einem ähnlichen Datenstrukturierungsformat erzielt werden."
Die Entwickler stellten wirklich fest, dass sie JSON problemlos zum Erstellen von AJAX-Anwendungen verwenden konnten, und viele entschieden sich für XML anstelle von XML. Ironischerweise hat das Interesse an AJAX zu einer Explosion der Popularität von JSON geführt. Um diese Zeit erregte JSON die Aufmerksamkeit der Blogosphäre.
Im Jahr 2006
beschwerte sich Dave Weiner, ein produktiver Blogger und Entwickler einer Reihe von XML-Technologien wie RSS und XML-RPC, dass JSON XML ohne guten Grund neu erfand:
„Natürlich kann ich ein Verfahren zum Parsen von [JSON] schreiben, aber schauen Sie, wie weit sie bei der Neuerfindung der Technologie gegangen sind: Aus irgendeinem Grund ist XML für sie nicht gut genug (ich frage mich, warum). Wer hat diese Parodie geschaffen? Lass uns einen Baum finden und einen Kerl aufhängen. Jetzt sofort".
Weiners Enttäuschung ist leicht zu verstehen. XML wurde noch nie besonders geliebt. Sogar Weiner selbst
sagte, er mochte XML nicht . XML wurde jedoch als universelles System für jede erdenkliche Anwendung entwickelt. XML ist eigentlich eine Metasprache, mit der Sie Domänensprachen für einzelne Anwendungen definieren können - zum Beispiel RSS und SOAP. Weiner ist der Ansicht, dass es wichtig ist, einen Konsens über alle Vorteile des gemeinsamen Austauschformats zu erzielen. Seiner Meinung nach kann die Flexibilität von XML alle Anforderungen erfüllen. JSON ist jedoch ein Format, das keine Vorteile gegenüber XML bietet, mit Ausnahme der Junk-Entfernung, die XML so flexibel gemacht hat.
Crockford sah Weiners Blogpost und kommentierte. Als Antwort auf den Vorwurf, dass JSON XML neu erfindet, schrieb Crockford:
" Das
Rad neu zu erfinden
ist gut, weil man es rund machen kann .
"JSON vs XML
Bis 2014 wurde JSON offiziell als ECMA- und RFC-Standard anerkannt. Er hat seinen MIME-Typ bekommen. JSON hat die großen Ligen betreten.
Warum ist JSON viel beliebter als XML geworden?
Auf
JSON.org listet Crockford einige der
Vorteile von JSON gegenüber XML auf . Er schreibt, dass JSON sowohl für Menschen als auch für Maschinen leichter zu verstehen ist, da seine Syntax minimal und seine Struktur vorhersehbar ist. Andere Blogger
erwähnen XML-Ausführlichkeit und "Tag Tax". Jedes öffnende Tag in XML muss ein schließendes Tag haben, was viele redundante Informationen bedeutet. Dies macht XML viel größer als das entsprechende JSON-Dokument, aber was noch wichtiger ist, aus diesem Grund ist das XML-Dokument schwerer zu lesen.
Crockford
nannte einen weiteren großen Vorteil von JSON: Es wurde ursprünglich als Format für den Austausch strukturierter Informationen zwischen Programmen entwickelt. Obwohl XML für denselben Zweck verwendet wurde, wurde es ursprünglich als Dokumentauszeichnungssprache entwickelt. Es entstand aus SGML (Standard Generalized Markup Language), das sich wiederum aus der Scribe-Markup-Sprache entwickelte, die für Markup-Text wie LaTeX vorgesehen ist. In XML kann es innerhalb eines Tags einen sogenannten „gemischten Inhalt“ geben, dh Text mit eingebetteten Tags, die Wörter oder Phrasen umgeben. Es ähnelt einem Editor, der ein Manuskript mit einer roten oder blauen Markierung markiert, einer Art Metapher für die Markup-Sprache. JSON hingegen unterstützt kein genaues Analogon gemischter Inhalte, was eine Vereinfachung der Struktur bedeutet. Das Dokument wird am besten in Form eines Baums dargestellt, aber Crockford gab die Idee des Dokuments auf und konnte JSON auf Wörterbücher und Arrays bekannter Elemente beschränken, die alle Programmierer zum Erstellen ihrer Programme verwenden.
Schließlich ist meine eigene Vermutung, dass die Komplexität von XML nicht gefallen hat, und das lag wirklich an seiner Vielfalt. Auf den ersten Blick ist es schwierig, zwischen dem XML selbst und seinen Subsprachen wie RSS, ATOM, SOAP oder SVG zu unterscheiden. In den ersten Zeilen eines typischen XML-Dokuments wird die XML-Version und anschließend die spezifische Subsprache festgelegt, mit der das XML-Dokument übereinstimmen muss. Dies sind viele Optionen im Vergleich zu JSON, das so einfach ist, dass niemals eine neue Version der JSON-Spezifikation geschrieben wird. Bei dem Versuch, ein einziges Datenaustauschformat für alles zu erstellen, fielen XML-Entwickler der klassischen Programmiererfalle zum Opfer: übermäßige technische Komplikationen. XML ist so allgemein, dass es schwierig ist, es für etwas Einfaches zu verwenden.
Im Jahr 2000 begann eine Kampagne, um HTML mit dem XML-Standard in Einklang zu bringen. Veröffentlichung einer Spezifikation für XML-kompatibles HTML, später als XHTML bekannt. Einige Browserhersteller begannen sofort, den neuen Standard zu unterstützen, aber es wurde schnell klar, dass die breite Öffentlichkeit, die mit HTML arbeitet, ihre Gewohnheiten nicht ändern wollte. Der neue Standard erforderte eine strengere XHTML-Validierung als für HTML üblich, aber zu viele Websites waren von freien HTML-Regeln abhängig. Bis 2009 hatten Aktivisten aufgehört, eine zweite Version von XHTML zu schreiben, als klar wurde, dass die Zukunft im HTML5-Standard lag, der keine XML-Konformität erforderte.
Wenn die Bemühungen von XHTML erfolgreich wären, würde XML möglicherweise zu einem gemeinsamen Datenformat werden, wie die Entwickler gehofft hatten. Stellen Sie sich eine Welt vor, in der HTML-Dokumente und API-Antworten genau dieselbe Struktur haben. In einer solchen Welt ist JSON möglicherweise nicht so populär geworden wie heute. Aber ich betrachte das Scheitern von XHTML als eine Art moralische Niederlage für das XML-Lager. Wenn XML HTML nicht hilft, gibt es möglicherweise bessere Tools für andere Anwendungen. In der realen Welt ist es leicht zu verstehen, warum das einfache und hochspezialisierte JSON-Format so erfolgreich war.