JSON vs XML: une comparaison pratique

XML précédant JSON d'une décennie était le choix par défaut pour les services web (SOAP, RSS, la plupart des intégrations d'entreprise) tout au long des années 2000. JSON ne l'a pas dépassé en capacité, XML peut représenter tout ce que JSON peut et plus ; il a gagné en poids et en direct pour le travail spécifique de déplacer des données entre un serveur et un client.

Les mêmes données, deux manières

<user>
  <name>Ada Lovelace</name>
  <age>36</age>
  <active>true</active>
  <skills>
    <skill>mathematics</skill>
    <skill>writing</skill>
  </skills>
</user>

{
  "user": {
    "name": "Ada Lovelace",
    "age": 36,
    "active": true,
    "skills": ["mathematics", "writing"]
  }
}

La version XML nécessite une balise de fermeture pour chaque ouverture, et un élément <skill> répété pour représenter une liste, car XML n'a pas de syntaxe native de tableau ; un élément <skills> avec plusieurs enfants <skill> pourrait tout aussi facilement être un seul enfant <skill>, et seul un schéma ou une convention indique au lecteur lequel. Les [ ] de JSON disent “liste” de manière non équivoque en deux caractères.

Là où XML gagne encore

Attributs joints au contenu. <price currency="USD">42.00</price> attache des métadonnées à une valeur sans inventer un objet conteneur. JSON n'a pas de concept d'attribut ; les mêmes données deviennent {"price": {"value": 42.00, "currency": "USD"}} ou une convention comme une clé @currency, toutes deux moins directes que la syntaxe native de XML pour exactement cette forme.

Contenu mixte. Un paragraphe de texte avec du balisage en ligne, <p>Some <b>bold</b> text</p>, est la force native de XML, c'est pourquoi les formats de document (DocBook, la plupart des flux de publication, SVG) l'utilisent encore. JSON n'a pas de moyen d'entremêler texte et balisage ; représenter un riche document en JSON signifie généralement un arbre de nœuds typés, ce qui est plus de code à écrire et à lire que le balisage que XML vous donne déjà gratuitement.

Espaces de noms et schémas stricts. XML Schema (XSD) et les espaces de noms permettent à une grande organisation de mélanger des vocabulaires de sources différentes dans un document sans collisions de noms, avec des outils qui existent depuis plus de vingt ans. JSON Schema existe et fait un travail réel (le Générateur de JSON Schéma en infère un à partir d'un document réel), mais il est plus jeune et moins universellement déployé que XSD dans les grands systèmes d'entreprise.

Là où JSON gagne, ce qui est la plupart des API

Poids. Pas de balises de fermeture signifie moins à transmettre et moins à analyser pour les mêmes données, souvent avec une grande marge sur les documents profondément imbriqués.

Correspondance directe aux propres structures de données d'un programme. JSON.parse en JavaScript, ou un équivalent en une ligne dans presque tous les autres langages, transforme un document JSON en les types natifs d'objet et de tableau de ce langage sans modèle intermédiaire. XML nécessite un DOM, ou une classe générée par un schéma, assis entre le texte et les données qu'un programme utilise réellement.

Pas de questions de typage implicite. Chaque valeur XML est du texte sauf si quelque chose d'externe (un schéma, une convention) dit le contraire ; <age>36</age> est une chaîne contenant “36” à moins qu'on ne dise que c'est un nombre. Les types number, boolean, et null de JSON sont explicites dans la syntaxe elle-même, donc il n'y a rien à configurer ou à deviner.

En pratique

Les nouvelles API REST sont définies sur JSON presque sans exception aujourd'hui. XML persiste là où ses propres forces sont essentielles : les services SOAP dans les anciens systèmes d'entreprise, les flux RSS et Atom, SVG et autres formats natifs de balisage, et là où les attributs ou le contenu mixte sont la forme réelle des données plutôt qu'un ajustement maladroit.

Convertir entre les deux

Le Convertisseur JSON en XML fonctionne dans les deux sens, avec des contrôles pour les préfixes d'espaces de noms et si une valeur donnée devient un attribut XML ou un élément enfant, car ce choix n'a pas de seule réponse correcte et dépend de ce qui consomme la sortie. Il utilise le DOMParser du navigateur pour lire XML plutôt qu'un analyseur fait à la main, et chaque valeur revient en tant que chaîne à l'entrée, ce que l'outil indique plutôt que deviner en silence des types que XML ne porte pas.