Un examen approfondi de JSON par rapport à XML, partie 1 : l'historique de chaque norme

Du bureau au Web et au mobile, presque toutes les applications informatiques que nous utilisons aujourd'hui reposent sur l'une des deux principales normes de messagerie : JSON et XML. Aujourd'hui, JSON est le format le plus utilisé, mais il n'a dépassé XML qu'au cours des cinq dernières années. Une recherche rapide en ligne pour "JSON vs. XML" apportera d'innombrables articles et billets de blog comparant les deux normes, et équivalant à un biais en expansion progressive louant la simplicité de JSON et critiquant la verbosité de XML. De nombreux articles insistent sur le fait que JSON est supérieur à XML en raison de sa sémantique concise et de la réduction de XML en tant que norme inefficace et déroutante du passé. À première vue, JSON semble être le plus populaire. JSON est-il simplement meilleur que XML ? La bataille de « JSON contre XML » pourrait aller à JSON en surface, mais en profondeur, il y a plus qu'il n'y paraît.

Dans la partie 1 de cet article, nous allons :

1. Examinez de plus près l'histoire du Web pour découvrir l'objectif initial de XML et de JSON.
2. Considérez l'évolution des tendances logicielles ces dernières années pour déterminer pourquoi JSON est devenu plus populaire que XML.

L'histoire de JSON et XML

Pour découvrir la raison de la popularité de JSON par rapport à XML, explorons l'histoire du Web et comment son évolution du Web 1.0 au Web 2.0 a influencé les tendances de développement.

Le Web 1.0 : HTML

Le début des années 1990 a marqué l'aube du Web 1.0. HTML a été introduit en 1991 et a été largement adopté par les universités, les entreprises et les organisations gouvernementales comme langage du Web. Le HTML est issu du SGML, ou "Standard Generalized Markup Language", inventé dans les années 1970 par IBM. En plus de l' adoption massive, HTML a connu une adaptation massive - des extensions ont été intégrées pour prendre en charge le multimédia, l'animation, les applications en ligne, le commerce électronique, etc. En tant que dérivé de SGML, HTML manquait d'une spécification stricte pour empêcher les entreprises de l'étendre librement pour répondre à des exigences qui dépassaient le concept d'origine. Le concours du navigateur Web le plus populaire entre Netscape et Microsoft a fait des progrès rapides, mais il a également conduit à une fragmentation incessante de la norme. La concurrence féroce a entraîné une "catastrophe de divergence" car l'augmentation du HTML par les deux sociétés a amené les navigateurs à prendre en charge leurs propres versions uniques de HTML. Cette catastrophe de divergence est devenue un énorme problème pour les applications Web, les développeurs ayant du mal à écrire du code interopérable pour les navigateurs.

Le Web 1.1 : XML + HTML = XHTML

À la fin des années 1990, un groupe de personnes, dont Jon Bosak, Tim Bray, James Clark et d'autres, a inventé XML : le « eXtensible Markup Language ». Comme SGML, XML n'est pas lui-même un langage de balisage, mais une spécification pour la définition des langages de balisage. XML était une évolution de SGML, conçu pour fournir un moyen de définir et d'appliquer un contenu structuré. Considéré comme « le Saint Graal de l'informatique » ¹ , le langage XML s'est efforcé « de résoudre le problème de l'échange universel de données entre systèmes dissemblables » (Dr Charles Goldfarb) ² . Au lieu de la fragmentation continue du HTML, le Comité du World Wide Web (W3C) a été formé pour favoriser la compatibilité et l'accord au sein de l'industrie dans l'adoption de nouvelles normes pour le World Wide Web. ³ Le W3C s'est mis à transformer HTML en une application XML, le résultat étant XHTML.

XHTML était une grande initiative qui a attiré l'attention sur XML, mais ce n'est qu'une petite partie de ce qu'est XML.

XML a permis à l'industrie de spécifier, avec une sémantique stricte, des langages de balisage personnalisés pour n'importe quelle application. Avec le mot-clé « sémantique stricte », XML a défini une norme qui pouvait affirmer l'intégrité des données dans n'importe quel document XML, de n'importe quel sous-langage XML. Pour les éditeurs de logiciels développant des applications d'entreprise distribuées qui s'interfacent avec des systèmes disparates, un langage de balisage capable d'affirmer l'intégrité de ses données était important. En définissant un contenu structuré avec XML, les entreprises ont tiré parti des fonctionnalités de cette technologie pour interagir avec n'importe quelle plate-forme, renforcer l'intégrité des données de chaque échange de données et réduire systématiquement le risque logiciel de leurs systèmes. Pour l'industrie, XML a fourni une technologie pour stocker, communiquer et valider tout type de données, sous une forme que les applications sur n'importe quelle plate-forme peuvent facilement lire et traiter. Pour HTML, XML promettait de résoudre la « catastrophe de la divergence ».

Java et .NET

Au début des années 2000, le web était gouverné par deux sociétés : Sun et Microsoft. À l'époque, le paysage des langages de programmation était fortement orienté côté serveur. L'architecture commune des applications Web reposait sur des serveurs affichant des pages HTML sur le back-end à livrer au navigateur. Cette approche a mis en lumière les technologies back-end, qui ont à leur tour popularisé les principales plateformes back-end : Java et C#.NET. Développé par Sun Microsystems, Java a dirigé la nouvelle génération de langages de programmation orientés objet qui ont résolu le problème inter-architecture avec sa nouvelle approche « écrire une fois, exécuter n'importe où » ⁴ . Microsoft a suivi avec .NET, C# et le Common Language Runtime (CLR) et a jeté son dévolu sur XML comme approche de choix pour résoudre le casse-tête de l'interopérabilité des données. Microsoft est devenu le plus grand défenseur de XML, l'entreprise ayant choisi XML comme partie intégrante de son importante initiative .NET. Annoncées comme « une plate-forme pour les services Web XML », ⁵ les applications .NET ont été conçues pour utiliser XML pour la communication avec d'autres plates-formes. Sélectionné comme norme d'échange de données de Microsoft, XML a été intégré dans ses produits serveurs phares, tels que SQL Server et Exchange.

Le Web 1.2 : AJAX

La livraison de pages HTML pré-rendues au navigateur n'était pas évolutive et le Web avait besoin d'une alternative. Chaque action de l'utilisateur nécessitant le chargement d'une nouvelle page à partir du serveur, la charge du processus et la consommation de bande passante devenaient une préoccupation à mesure que de plus en plus de personnes gonflaient le Web.

Netscape et Microsoft se sont efforcés de résoudre ce problème avec la diffusion de contenu asynchrone : ActiveX et JavaScript. En 1998, l'équipe Microsoft Outlook Web Access a développé le concept derrière ActiveX ⁶ , qui a ensuite été implémenté par Mozilla, Safari, Opera et d'autres navigateurs en JavaScript en tant qu'objet XMLHttpRequest .

AJAX est né de l'ActiveX de Microsoft et du JavaScript de Netscape.

Le terme AJAX, abréviation de « JavaScript et XML asynchrones », en est venu à représenter un large éventail de technologies Web qui peuvent être utilisées pour mettre en œuvre des applications Web qui communiquent avec des serveurs en arrière-plan sans nécessiter le rechargement d'une page. Dans l'article qui a inventé le terme AJAX, ^{7 8} Jesse James Garrett a décrit les principaux concepts :

1. HTML (ou XHTML) et CSS pour la présentation.
2. Le Document Object Model (DOM) pour l'affichage dynamique et l'interaction avec les données.
3. XML pour l'échange de données, et XSLT pour sa manipulation.
4. L'objet XMLHttpRequest pour la communication asynchrone.
5. JavaScript pour rassembler ces technologies.

La diffusion de contenu asynchrone s'avérant réduire la charge du serveur et économiser une bande passante considérable, AJAX a changé la donne. L'introduction de XMLHttpRequest dans les navigateurs a permis aux développeurs d'implémenter une logique plus complexe dans le frontal. Google a fait un large déploiement d'AJAX multi-navigateur conforme aux normes avec Gmail en 2004 et Google Maps en ^2005.9 Et, en octobre 2004, la version bêta publique de Kayak.com a été parmi les premières utilisations à grande échelle d'AJAX pour le commerce électronique. ^dix

Le Web 2.0 : Applications d'une seule page

L'adoption d'AJAX comme architecture évolutive pour les applications Web a conduit à l'aube du Web 2.0 : l'application monopage (SPA). ¹¹ Au lieu de recharger la page entière pour chaque interaction de l'utilisateur, les SPA réécrivent dynamiquement la page actuelle dans le navigateur. En plus d'une réduction considérable de la charge du serveur et de la consommation de bande passante, l'approche SPA a permis aux applications Web de ressembler aux applications de bureau en raison de l'expérience transparente et ininterrompue lors de l'interaction de l'utilisateur.

En avril 2002, Stuart Morris a écrit l'un des premiers SPA sur slashdotslash.com ¹² , et plus tard la même année, Lucas Birdeau, Kevin Hakman, Michael Peachey et Evan Yeh ont décrit une application d'une seule page dans le brevet américain 8,136,109. ¹³ Le brevet décrivait des navigateurs Web utilisant JavaScript pour afficher l'interface utilisateur, exécuter la logique d'application et communiquer avec un serveur Web.

Gmail de Google, Google Maps et la version bêta publique de Kayak ont ​​déclenché une nouvelle ère de développement d'applications Web. Les navigateurs activés avec AJAX permettent aux développeurs d'écrire des applications riches pour le Web. La sémantique simple de JavaScript a rendu le développement d'applications possible pour les programmeurs de tout calibre. La barrière à l'entrée dans le développement de logiciels a été considérablement réduite et les développeurs individuels du monde entier ont commencé à contribuer avec leurs propres bibliothèques et frameworks. Les bibliothèques populaires telles que jQuery, qui normalisent le comportement AJAX sur les navigateurs de différents fabricants, ont encore fait progresser la révolution AJAX.

La montée de JSON

En avril 2001, Douglas Crockford et Chip Morningstar ont envoyé le premier message JSON depuis un ordinateur du garage Morningstar's Bay Area. Crockford et Morningstar essayaient de créer des applications AJAX bien avant que le terme "AJAX" ne soit inventé, mais la prise en charge du navigateur pour ce qu'ils tentaient de réaliser n'était pas bonne. Ils souhaitaient transmettre des données à leur application après le chargement de la page, mais n'avaient pas trouvé de moyen de permettre à cela de fonctionner sur tous les navigateurs.

En 2001, le développement d'AJAX ne faisait que commencer et il n'existait pas encore de forme interopérable de l'objet XMLHttpRequest dans Internet Explorer 5 et Netscape 4. Crockford et Morningstar ont donc utilisé une approche différente qui fonctionnait dans les deux navigateurs.

Le premier message JSON ressemblait à ceci :

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

Ce message est en fait un document HTML contenant du JavaScript, et seule une petite partie du message ressemble à JSON tel que nous le connaissons aujourd'hui. Crockford et Morningstar ont pu charger des données de manière asynchrone en pointant un <iframe> vers une URL qui renverrait un document HTML comme celui ci-dessus. Lorsque la réponse était reçue, le JavaScript dans le HTML était exécuté et, en contournant les protections du navigateur empêchant les sous-fenêtres d'accéder au parent, le littéral d'objet était renvoyé au cadre principal de l'application. Cette technique basée sur les cadres, parfois appelée « technique des cadres cachés », était couramment utilisée à la fin des années 90 avant la mise en œuvre généralisée de XMLHttpRequest . ¹⁴

Cette approche a séduit les développeurs car elle offrait une interopérabilité entre tous les navigateurs. Étant donné que le message n'est que du JavaScript, il ne nécessite aucune analyse particulière. L'idée d'utiliser JavaScript de cette manière était si simple que Crockford lui-même a déclaré qu'il n'était pas la première personne à le faire - il prétend que quelqu'un chez Netscape utilisait JavaScript pour communiquer des informations dès ^1996.15

Crockford et Morningstar ont réalisé qu'ils avaient quelque chose qui pouvait être utilisé dans toutes sortes d'applications. Ils ont nommé leur format JSON, qui est l'abréviation de "JavaScript Object Notation". Ils ont commencé à le présenter aux clients, mais ont rapidement constaté que beaucoup n'étaient pas disposés à tenter leur chance avec une nouvelle technologie dépourvue de spécifications officielles. Alors Crockford a décidé qu'il en écrirait un. En 2002, Crockford a acheté le domaine JSON.org et mis en place la grammaire JSON et une implémentation de référence d'un parseur. Le site Web est toujours en place, bien qu'il comprenne désormais un lien proéminent vers la norme JSON ECMA ratifiée en ^2013.16 Après avoir mis en place le site Web, Crockford n'a guère fait plus pour promouvoir JSON, mais a rapidement trouvé des personnes soumettant des implémentations d'analyseur JSON pour différents langages de programmation. L'origine de JSON est clairement liée à JavaScript, mais il est devenu évident que JSON était bien adapté pour échanger des données entre des langages arbitraires.

JSON en AJAX

En 2005, Jesse James Garrett a inventé le terme "AJAX" dans un article de blog, où il a souligné qu'AJAX n'était pas une nouvelle technologie, mais plutôt "plusieurs technologies, chacune florissante en soi, se réunissant de nouvelles manières puissantes". ¹⁶ Son article de blog décrit ensuite comment les développeurs peuvent exploiter JavaScript et XMLHttpRequest pour créer de nouveaux types d'applications plus réactives et avec état que la page Web classique. Il a cité Gmail, Google Maps et Flickr comme exemples de sites Web utilisant les techniques AJAX. Bien que "X" dans "AJAX" signifiait XML, Garrett a désigné JSON comme une alternative tout à fait acceptable. Il a écrit que "XML est le moyen le plus développé d'obtenir des données dans et hors d'un client AJAX, mais il n'y a aucune raison pour que vous ne puissiez pas obtenir les mêmes effets en utilisant une technologie comme JavaScript Object Notation ou tout autre moyen similaire de structuration des données." ¹⁷

JavaScript et JSON étaient sans équivoque destinés à être ensemble. La sémantique de JSON correspond directement à JavaScript, ce qui en fait le format natif d'échange de données pour le langage. Les développeurs ont rapidement découvert que JSON était plus facile à utiliser en JavaScript, et beaucoup en sont venus à le préférer à XML.

Alors que JSON attirait l'attention de la blogosphère, la prolifération de JSON avait commencé.

Pourquoi JSON est devenu plus populaire que XML

JSON est le format natif des données dans les applications JavaScript. Avec la popularisation de JavaScript au cours de la dernière décennie, plus de messages JSON ont été créés que tout autre format de données. L'écriture d'applications en JavaScript rend presque obligatoire l'utilisation de JSON pour l'échange de données. D'autres formats sont possibles, mais ils demandent plus d'efforts qu'avec JSON. Avec la popularité croissante de JavaScript pour le développement d'applications, JSON a suivi de près dans son sillage en tant que format d'échange de données facile à utiliser et intégré de manière native.

En ce qui concerne la blogosphère, plus d'articles, d'exemples et de tutoriels ont été écrits sur JavaScript (et donc JSON) que sur toute autre plate-forme de programmation.

L'histoire et l'évolution du Web ont joué un rôle important dans la vulgarisation de JSON. Selon Stack Overflow, plus de questions sont désormais posées sur JSON que sur les autres formats d'échange de données. ¹⁸

Selon Google Trends, un profil similaire est observé en comparant l'intérêt de recherche pour JSON et XML. ¹⁹

La prolifération de JavaScript signifie-t-elle que JSON est meilleur que XML ?

Les communautés de développeurs insistent sur le fait que JSON est devenu plus populaire que XML en raison de sa portée déclarative concise et de sa sémantique simple. Douglas Crockford lui-même résume certains des avantages de JSON sur JSON.org : "JSON est plus facile à comprendre pour les humains et les machines, car sa syntaxe est minimale et sa structure est prévisible." ²⁰ D'autres détracteurs de XML se sont concentrés sur la verbosité de XML comme étant « la taxe entre parenthèses ». ²¹ Le format XML exige que chaque balise d'ouverture corresponde à une balise de fermeture, ce qui entraîne des informations redondantes qui peuvent rendre un document XML beaucoup plus volumineux qu'un document JSON équivalent lorsqu'il n'est pas compressé. Et, peut-être plus important encore, les développeurs disent : "cela rend également un document XML plus difficile à lire". ²²

JSON a été facilement salué en raison de sa simplicité et de sa sémantique concise, et XML étiqueté comme une norme désuète du passé en raison de sa verbosité et de sa complexité apparemment excessive. De nombreux articles et billets de blog offrent une perspective limitée lors de la comparaison de JSON à XML, ce qui amène les lecteurs à croire que JSON remplace XML. Ce n'est pas le cas!

La perspective limitée offerte par les articles et les billets de blog a conduit les lecteurs à considérer XML comme obsolète, laissant beaucoup d'entre eux ignorants des fonctionnalités puissantes qui peuvent les aider à améliorer l'architecture de leur logiciel et sa résilience au changement ainsi qu'à réduire systématiquement les risques logiciels.

JSON est plus populaire que XML en raison de la prédominance de JavaScript en tant que langage le plus largement utilisé aujourd'hui. Avec l'influence de JavaScript sur les tendances logicielles au cours de la dernière décennie, JSON continue de recevoir de plus en plus d'attention que tout autre format d'échange de données. La blogosphère n'hésite pas à répéter que "JSON est meilleur que XML", mais le plus souvent, ces déclarations ne sont pas justifiées ou sont étayées par des comparaisons simplistes concernant la sémantique et la verbosité. Alors, est-ce que l'une ou l'autre des normes est meilleure que l'autre ? La réponse à cette question ne peut provenir que d'une évaluation plus approfondie de chaque norme.

Conclusion

De 1990 à aujourd'hui, le web a parcouru un long chemin. La guerre des navigateurs entre Netscape et Microsoft a conduit à une catastrophe de divergence du HTML, et une solution était nécessaire pour sauver le Web. XML a été inventé pour formaliser XHTML et a fourni une solution du Saint Graal pour l'informatique dans son ensemble. Du rendu de pages HTML complètes par des serveurs back-end à AJAX et SPA, les tendances en matière d'architecture Web et de développement de navigateurs ont mis l'accent sur JavaScript, orientant les développeurs du monde entier vers JSON.

La popularité de JSON est corrélée à celle de JavaScript. Avec sa facilité d'utilisation et sa courte courbe d'apprentissage, JavaScript a amené plus de nouveaux développeurs à écrire des logiciels que tout autre langage. Avec l'intégration native de JSON avec la plate-forme de développement la plus populaire, il n'est pas surprenant que plus de questions soient posées sur JSON sur Stack Overflow que sur tout autre format d'échange de données.

Avec les tendances logicielles de ces dernières années qui ont amené plus de développeurs JavaScript dans l'industrie, JSON a gagné le titre de "format d'échange de données le plus populaire".

En surface, la bataille de "JSON contre XML" revient à JSON, mais en profondeur, il y a plus qu'il n'y paraît.

Dans la partie 2 de cet article, nous examinerons de plus près les forces et faiblesses techniques de JSON et XML, et évaluerons la pertinence de chaque norme pour les applications courantes et l'entreprise. Un examen plus approfondi de «l'échange de données» révélera l'étendue de son influence sur le risque logiciel de l'application dans son ensemble. Une meilleure compréhension des différences fondamentales entre JSON et XML permettra aux développeurs de mieux évaluer le risque logiciel de chaque norme par rapport aux exigences de leur projet, afin de permettre aux développeurs de créer des logiciels plus stables et plus résistants aux bogues et aux erreurs futures. inconnues.

Soit dit en passant, une particularité intéressante de la spécification JSON est que vous ne pouvez pas convertir des objets JavaScript avec des relations bidirectionnelles, où les propriétés enfant font référence aux propriétés parent, en JSON. Cela entraînerait une Uncaught TypeError: Converting circular structure to JSON . Pour un hack autour de cette limitation, consultez Prise en charge des relations bidirectionnelles dans JSON .

Les références

1. Internet : une encyclopédie historique. Chronologie, tome 3, p. 130 (ABC-CLIO, 2005)

2. Manuel de métadonnées, de sémantique et d'ontologies, p. 109 (World Scientific, décembre 2013)

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

4. "JavaSoft livre Java 1.0" (Sun Microsystems, janvier 1996)

5. Activation spatiale de l'Internet de nouvelle génération (David Engen, janvier 2002)

6. L'histoire de XMLHTTP (AlexHopmann.com, janvier 2007)

7. Début Ajax - Page 2 (Wiley Publishing, mars 2007)

8. Ajax : une nouvelle approche des applications Web (Jesse James Garrett, février 2005)

9. Une brève histoire de l'Ajax (Aaron Swartz, décembre 2005)

10. "Qu'est-ce que Kayak.com ?" (Document d'information sur l'entreprise, octobre 2008)

11. Inner-Browsing : Étendre le paradigme de la navigation par navigation (Netscape, mai 2003)

12. "Un site Web autonome utilisant DHTML" (SlashDotSlash.com, juillet 2012)

13. Livraison des données et des informations de formatage pour permettre la manipulation côté client (US Patent Bureau, avril 2002)

14. "Qu'est-ce que l'Ajax ?" Ajax professionnel, 2e éd. (Wiley, mars 2007)

15. Douglas Crockford : La saga JSON (Yahoo !, juillet 2009)

16. Norme ECMA 404 (ECMA International, décembre 2017)

17. Ajax : une nouvelle approche des applications Web (Jesse James Garrett, février 2005)

18. Tendances de débordement de pile (débordement de pile, 2009-2019)

19. Tendances Google (Google, 2004-2019)

20. JSON : l'alternative sans gras à XML (Crockford, 2006)

21. XML : La taxe sur les tranches d'angle (Coding Horror, mai 2008)

22. Xml suce (WikiWikiWeb, 2016)