JSON vs XML

Origines : un langage de balisage contre un format de données

L’ancêtre d’XML est le SGML, et son objectif de conception était de baliser des documents : de la prose mêlant paragraphes, emphase et structure. Voilà pourquoi XML, seul des deux, prend en charge le contenu mixte — du texte avec du balisage en ligne comme <title>Learning <em>XML</em></title> — et pourquoi il a développé attributs, références d’entités et un modèle de traitement lourd. JSON a été extrait des littéraux d’objets JavaScript vers 2001 pour exactement un but : faire circuler des données structurées entre programmes avec la plus petite grammaire possible. Pas de contenu mixte en JSON, pas de machinerie d’entités, pas d’arbre documentaire — objets, tableaux et quatre types scalaires composent l’univers entier.

Syntaxe : la taxe de balisage, les attributs et le tableau absent

Chaque élément XML s’ouvre et se ferme, donc une valeur simple coûte deux balises : <price>19.99</price>. XML propose une orthographe alternative — <price currency="EUR">19.99</price> — et le choix attribut ou élément alimente le débat depuis deux décennies sans réponse universelle. JSON a exactement une écriture pour une paire clé/valeur et une pour une liste. Point crucial : JSON a des tableaux natifs ; XML n’a aucun type tableau. Une liste s’exprime en répétant un élément, ce qui oblige chaque outil JSON vers XML à s’accorder sur une convention pour nommer et envelopper les éléments répétés.

Schémas et espaces de noms : là où XML se justifie encore

XSD est l’avantage discret d’XML en entreprise : un langage de schéma mature, avec types dérivés, contraintes de cardinalité, facettes de motif et deux décennies d’outillage capable de valider un document et de signaler précisément quel élément a violé quelle règle. JSON Schema poursuit le même but sous une autre forme — il est expressif, prend en charge la logique conditionnelle et est devenu le langage de contrat de facto des API modernes — mais sa longue histoire de brouillons fait que l’outillage varie davantage dans ce qu’il accepte. Les deux écosystèmes peuvent être stricts ; celui d’XML est simplement plus ancien.

Les espaces de noms sont l’autre trait durable d’XML. Une page XHTML peut embarquer du SVG et du MathML sans collision de clés parce que chaque vocabulaire porte son propre URI. JSON n’a pas de mécanisme équivalent — les collisions de noms s’évitent par convention, ou par des conceptions en couches comme JSON-LD qui attachent le contexte explicitement.

Taille, flux et critères de choix

À données égales, les charges utiles XML sont généralement plus grosses : les balises fermantes à elles seules doublent à peu près le balisage par élément, et les styles lourds en attributs ajoutent encore. Les deux formats se compressent bien avec gzip — la redondance d’XML est très compressible — mais le surcoût de base ne se referme que rarement entièrement. Côté flux, l’écosystème de parseurs d’XML est plus profond : les parseurs push SAX et StAX ont été conçus pour des documents trop gros pour la mémoire, et chaque plateforme en embarque un. Des parseurs JSON en flux existent et sont excellents, mais l’analyse d’un document entier reste le défaut commun.

Choisissez JSON pour tout ce qu’échangent deux programmes : API web et mobiles, logs structurés, charges utiles entre services. Choisissez XML quand une spécification l’impose — piles SOAP, chaînes d’édition, formats Office, nombre de normes de santé et de finance — ou quand vous avez besoin de validation XSD et d’espaces de noms sur le fil. La recommandation s’inverse proprement : du JSON qui s’infiltre dans un pipeline de documents veut généralement devenir XML, et une API d’ère SOAP qui expose un JSON propre est un gain de migration, pas une trahison.