Comparaison JSON et XML
Je veux savoir lequel est le plus rapide: XML et JSON? Quand utiliser lequel?
Avant de répondre quand utiliser lequel, un peu de contexte:
edit: Je devrais mentionner que cette comparaison est vraiment du point de vue de les utiliser dans un navigateur avec JavaScript. Ce n'est pas la façon dont l'un ou l'autre format de données doit être utilisé, et il y a plein de bons analyseurs qui changeront les détails pour que ce que je dis ne le fasse pas tout à fait valable.
JSON est à la fois plus compact et (à mon avis) plus lisible. En transmission, il peut être "plus rapide" simplement parce que moins de données sont transférées.
Dans l'analyse, cela dépend de votre analyseur. Un analyseur transformant le code (qu'il s'agisse de JSON ou de XML) en une structure de données (comme une carte) peut tirer profit de la nature stricte de XML ( XML Schemas sans ambiguïté de la structure de données). Le type d'un élément (String/Number/NSON Object) peut être déduit syntaxiquement, par exemple:
myJSON = {"age" : 12,
"name" : "Danielle"}
L'analyseur n'a pas besoin d'être suffisamment intelligent pour se rendre compte que 12 représente un nombre (et Danielle est une chaîne comme une autre). Donc, en javascript, nous pouvons faire:
anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False
En XML, nous devrions faire quelque chose comme ceci:
<person>
<age>12</age>
<name>Danielle</name>
</person>
(mis à part, cela illustre le fait que XML est un peu plus détaillé; une préoccupation pour la transmission de données). Pour utiliser ces données, nous les exécuterions via un analyseur, puis nous appellerions quelque chose comme:
myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True
En fait, un bon analyseur pourrait bien taper la age pour vous (par contre, vous pourriez ne pas le vouloir). Ce qui se passe lorsque nous accédons à ces données, c'est qu'au lieu d'effectuer une recherche d'attribut comme dans l'exemple JSON ci-dessus, nous procédons à une recherche de carte sur la clé name. Il pourrait être plus intuitif de former le XML comme ceci:
<person name="Danielle" age="12" />
Mais il nous reste à faire des recherches sur carte pour accéder à nos données:
myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");
EDIT: Original:
Dans la plupart des langages de programmation (pas du tout, de loin), une recherche de carte telle que celle-ci sera plus coûteuse qu'une recherche d'attribut (comme nous l'avions précédemment lorsque nous avons analysé le JSON).
Ceci est trompeur: souvenez-vous qu'en JavaScript (et dans d'autres langages dynamiques) il n'y a aucune différence entre une recherche de carte et une recherche de champ. En fait, une recherche de champ est juste une recherche sur une carte.
Si vous voulez une comparaison vraiment utile, le mieux est de l’analyser - faites les analyses dans le contexte où vous prévoyez d’utiliser les données.
Au fur et à mesure que je tape, Felix Kling a déjà présenté une réponse assez succincte pour les comparer quant au moment de les utiliser, je ne vais donc pas aller plus loin.
plus rapide n'est pas un attribut de JSON ou XML ni un résultat qui donnerait une comparaison entre ceux-ci. Le cas échéant, il s'agit d'un attribut des analyseurs ou de la bande passante avec laquelle vous transmettez les données.
Voici (au début de) une liste des avantages et inconvénients de JSON et XML:
JSON
Pro:
- Une syntaxe simple, qui entraîne moins de "balisage", par rapport à XML.
- Facile à utiliser avec JavaScript car le balisage est un sous-ensemble de la notation littérale d'objet JS et possède les mêmes types de données de base que JavaScript.
- JSON Schema pour la description et la validation du type de données et de la structure
- JsonPath pour extraire des informations dans des structures profondément imbriquées
Con:
Syntaxe simple, seuls quelques types de données différents sont pris en charge.
Pas de support pour les commentaires.
XML
Pro:
- Balisage généralisé; il est possible de créer des "dialectes" pour tout type de projet
- XML Schema pour le type de données, validation de la structure. Permet également de créer de nouveaux types de données
- XSLT pour la transformation en différents formats de sortie
- XPath / XQuery pour extraire des informations dans des structures profondément imbriquées
- support intégré pour les espaces de noms
Con:
- Relativement verbeux comparé à JSON (plus de données pour la même quantité d’informations).
En fin de compte, vous devez décider de ce dont vous avez besoin . De toute évidence, les deux formats ont leurs cas d'utilisation légitimes. Si vous utilisez principalement JavaScript, vous devez utiliser JSON.
N'hésitez pas à ajouter le pour et le contre. Je ne suis pas un expert en XML;)
La vitesse de traitement n'est peut-être pas le seul facteur important; toutefois, car telle est la question, voici quelques chiffres dans un repère: JSON contre XML: Quelques chiffres précis sur la verbosité . Pour la rapidité, dans ce simple repère, XML présente une surcharge de 21% par rapport à JSON.
Une remarque importante à propos de la verbosité, comme le dit l'article, est la plainte la plus courante: ce n'est pas tellement pertinent en pratique (ni les données XML ni JSON ne sont généralement traitées par des humains, mais par des machines), même s'il s'agit de il faut un peu plus de temps pour compresser.
De plus, dans ce test de référence, une grande quantité de données a été traitée et une application Web typique ne transmet pas des morceaux de données d'une taille aussi grande que 90 Mo, et la compression peut ne pas être bénéfique (pour des morceaux de données suffisamment petits, un morceau compressé sera plus gros que le bloc non compressé), donc non applicable.
Néanmoins, si aucune compression n'est impliquée, JSON, comme de toute évidence terser, pèsera moins sur le canal de transmission, en particulier s'il est transmis via une connexion WebSocket, où l'absence de la surcharge HTTP classique peut faire la différence au détriment de JSON, encore plus important.
Après la transmission, les données doivent être consommées et cela compte dans le temps de traitement global. Si des données volumineuses ou complexes doivent être transmises, l'absence de schéma automatiquement vérifié par un analyseur syntaxique XML validant peut nécessiter un contrôle supplémentaire des données JSON. ces vérifications devraient être exécutées en JavaScript, ce qui n'est pas réputé être particulièrement rapide, ce qui peut entraîner une surcharge supplémentaire par rapport à XML dans de tels cas.
Quoi qu'il en soit, seuls les tests fourniront la réponse à votre cas d'utilisation particulier (si la vitesse est vraiment la seule chose à faire, et non standard, ni sécurité, ni intégrité…) .
Mise à jour 1: il convient de mentionner EXI, le format XML binaire, qui offre une compression moins coûteuse que l’utilisation de Gzip, ainsi que le traitement de sauvegarde nécessaire pour décompresser le XML compressé. EXI est à XML, ce que BSON est à JSON. Ayez un aperçu rapide ici, avec une référence à l'efficacité dans l'espace et dans le temps: EXI: Le dernier standard binaire? .
Mise à jour 2: il existe également un rapport de performances XML binaire, dirigé par le W3C, indiquant que l'efficacité, le faible volume de mémoire et l'encombrement de l'unité centrale, concerne également la zone XML: Efficient XML Interchange Evaluation .
Mise à jour 2015-03-01
Il convient de noter dans ce contexte que la surcharge HTTP a été soulevée: l'IANA a enregistré le codage EXI (le binaire XML efficace mentionné ci-dessus), sous la forme aa Content Coding pour le protocole HTTP (à côté de compresse , déflate et gzip ). Cela signifie que EXI est une option qui devrait pouvoir être comprise par les navigateurs parmi éventuellement d'autres clients HTTP. Voir Paramètres de protocole de transfert d'hypertexte (iana.org) .
J'ai trouvé cet article sur Digital Bazaar vraiment intéressant. Citant leurs citations de Norm:
À propos de JSON pros:
Si tout ce que vous voulez faire passer sont des valeurs atomiques, des listes ou des hachages de valeurs atomiques, JSON présente de nombreux avantages du XML: il est directement utilisable sur Internet, prend en charge une grande variété d’applications, il est facile d’écrire des programmes pour traiter JSON, il a peu de fonctionnalités en option, il est lisible par l'homme et raisonnablement clair, sa conception est formelle et concise, les documents JSON sont faciles à créer et il utilise Unicode. ...
À propos des pros XML:
XML gère remarquablement bien toute la richesse des données non structurées. Je ne suis pas du tout inquiet pour l’avenir de XML, même si sa mort est célébrée avec joie par un groupe de concepteurs d’API Web.
Et je ne peux pas résister à rentrer un "je vous l’ai dit!" jeton dans mon bureau. Je suis impatient de voir ce que font les gens JSON quand on leur demande de développer des API plus riches. Quand ils veulent échanger des données moins bien structurées, vont-ils les intégrer à JSON? Je vois des mentions occasionnelles d’un langage de schéma pour JSON, d’autres langues suivront-elles? ...
Je suis personnellement d'accord avec Norm. Je pense que la plupart des attaques contre XML proviennent de développeurs Web pour des applications typiques et pas vraiment de développeurs d'intégration. Mais c'est mon avis! ;)
Le langage XML (extensible Markup Language) est souvent utilisé XHR car il s’agit d’un langage de diffusion standard, utilisable par n’importe quel langage de programmation et supporté à la fois par le serveur et par le client. Il s’agit donc de la solution la plus flexible. Le code XML peut être séparé pour plusieurs parties afin qu'un groupe spécifié puisse développer la partie du programme sans affecter les autres parties. Le format XML peut également être déterminé par la DTD XML ou le schéma XML (XSL) et peut être testé.
Le format JSON est un format d’échange de données de plus en plus utilisé comme format possible pour les applications JavaScript. Fondamentalement, il s'agit d'un tableau de notation d'objet. JSON a une syntaxe très simple et peut donc être appris facilement. Et aussi le support JavaScript en analysant JSON avec la fonction eval. D'autre part, la fonction eval a des négatifs. Par exemple, le programme peut être très lent à analyser JSON et, pour des raisons de sécurité, le eval peut être très risqué. Cela ne veut pas dire que le JSON n’est pas bon, mais il faut faire plus attention.
Ma suggestion est que vous devriez utiliser JSON pour les applications avec échange de données léger, comme les jeux. Parce que vous n'avez pas à vous soucier vraiment de l'informatique, c'est très simple et rapide.
Le XML convient mieux aux grands sites Web, par exemple les sites de magasinage ou quelque chose du genre. Le XML peut être plus sécurisé et clair. Vous pouvez créer une structure de données et un schéma de base pour tester facilement la correction et la séparer facilement en plusieurs parties.
Je suggère que vous utilisiez XML à cause de la rapidité et de la sécurité, mais JSON pour des choses légères.
L'important dans JSON est de conserver le transfert de données crypté pour des raisons de sécurité. Nul doute que JSON est beaucoup plus rapide que XML. J'ai vu XML prendre 100ms alors que JSON ne prenait que 60ms. Les données JSON sont faciles à manipuler.