Pourquoi tout le monde choisit-il JSON plutôt que XML pour jQuery ?

Question

Je pensais que le XML était hautement portable et pouvait être utilisé comme une mini-base de données. J'ai vu XML utilisé partout. Je vois même de grandes entreprises passer à JSON . Même Microsoft a intégré un support pour JSON. Pourquoi tout ce battage autour de JSON ?

Answer 1

En fait, comme JSON est reconnu nativement par JavaScript, il est très léger, minimaliste et hautement portable car il ne repose que sur deux structures fondamentales :

• Une collection de paires nom/valeur. Dans divers langages, il s'agit d'un objet, d'un enregistrement, d'une structure, d'un dictionnaire, d'une table de hachage, d'une liste de clés ou d'un tableau associatif.
• Une liste ordonnée de valeurs. Dans la plupart des langages, il s'agit d'un tableau, d'un vecteur, d'une liste ou d'une séquence.

Answer 2

Le XML ne commence vraiment à briller que lorsque l'on commence à mélanger différents schémas à espacement de noms. C'est alors que JSON commence à perdre du terrain, mais si vous avez simplement besoin d'un format de sérialisation pour vos données, JSON est plus petit, plus léger, plus lisible et généralement plus rapide que XML.

Answer 3

Je trouve que l'un des grands avantages de JSON par rapport à XML est que je n'ai pas à décider comment formater les données. Comme certains l'ont montré, il existe de nombreuses façons de réaliser des structures de données, même simples, en XML - comme éléments, comme valeurs d'attributs, etc. Ensuite, il faut le documenter, écrire XML Schema ou Relax NG ou d'autres conneries... C'est le bazar.

XML a peut-être ses mérites, mais pour l'échange de données de base, JSON est beaucoup plus compact et direct. En tant que développeur Python, il n'y a aucune incompatibilité d'impédance entre les types de données simples en JSON et en Python. Ainsi, si j'écrivais un gestionnaire côté serveur pour une requête AJAX demandant les conditions d'enneigement d'une station de ski particulière, je construirais un dictionnaire comme suit :

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

Lorsqu'elle est traduite en JSON (à l'aide d'une bibliothèque comme 'simplejson' pour Python), la structure JSON résultante est presque identique (sauf que dans JSON, les booléens sont en minuscules).

Pour décoder cette structure, il suffit d'utiliser un analyseur JSON, que ce soit en Javascript ou en Objective-C pour une application iPhone native ou en C# ou un client Python. Les flottants seront interprétés comme des flottants, les chaînes de caractères comme des chaînes de caractères et les booléens comme des booléens. En utilisant la bibliothèque 'simplejson' en Python, un fichier simplejson.loads(some_json_string) me rendrait une structure de données complète comme celle que je viens de créer dans l'exemple ci-dessus.

Si j'écrivais du XML, je devrais décider s'il faut faire des éléments ou des attributs. Les deux solutions suivantes sont valables :

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

Je dois donc non seulement réfléchir aux données que je pourrais vouloir envoyer au client, mais aussi à la manière de les formater. Le XML, bien qu'il soit plus simple que le SGML ordinaire en étant plus strict dans ses règles, offre encore trop de façons de penser à ces données. Il faut ensuite les générer. Je ne pourrais pas simplement prendre un dictionnaire Python (ou une autre structure de données simple) et dire "va te transformer en mon XML". Je ne pourrais pas recevoir un document XML et dire immédiatement "va te transformer en objets et en structures de données" sans écrire un analyseur syntaxique personnalisé, ou sans exiger les frais généraux supplémentaires de XML Schema/Relax NG et autres problèmes de ce genre.

En résumé, il est beaucoup plus facile et direct de coder et de décoder des données en JSON, notamment pour les échanges rapides. Cela s'applique davantage aux personnes issues d'un langage dynamique, car les types de données de base (listes, dictionnaires, etc.) intégrés à JavaScript/JSON correspondent directement aux mêmes types de données ou à des types similaires en Python, Perl, Ruby, etc.

Answer 4

Les performances de JSON ne sont pas très différentes de celles de XML dans la plupart des cas. lisible pour les structures profondément imbriquées... vous rencontrerez []] }], ce qui rend le débogage difficile.

Answer 5

Il est léger par rapport au XML. Si vous devez évoluer, réduisez vos besoins en bande passante !

Comparer JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

à XML :

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>