XML vs JSON
Travailler avec plusieurs langages et/ou faire communiquer deux infrastructures différentes nécessite un format d'échange facile à appréhender et à manipuler. Mais encore faut-il que ce format soit implémenté ou implémentable facilement. C'est le rôle de deux formats aujourd'hui bien reconnus, le XML (eXtended Markup Langage) et JSON (JavaScript Object Notation).
Ces deux formats sont souples, efficaces, connus et surtout répandu. Les deux présentent des avantages et inconvénients. Alors comment faire un choix ?
Commençons par présenter les deux formats, en commençant pas XML.
XML et un format de données très simple à comprendre, on nomme des balises qui contiennent des valeurs. Chaque balise peut avoir des attributs et contenir d'autres balises. Prenons l'exemple d'une base de données d'auteurs, chaque auteur peut avoir écrit un ou plusieurs livres. Voici ce que l'on pourrait faire en XML pour représenter nos données:
<?xml version="1.0" ?>
<auteurs>
<auteur>
<nom>King</nom>
<prenom>Stephen</prenom>
<livres>
<livre>La ligne verte</livre>
<livre>Carrie</livre>
<livres>
</auteur>
<auteur>
<nom>Brown</nom>
<prenom>Dan</prenom>
<livres>
<livre>Anges et démons</livre>
<livre>Da Vinci Code</livre>
<livres>
</auteur>
</auteurs>
Effectivement, on pourrait rendre le format plus aggréable à lire, que ce soit humainement ou en terme de code:
<?xml version="1.0" ?>
<auteurs>
<auteur nom="King" prenom="Stephen">
<livres>
<livre>La ligne verte</livre>
<livre>Carrie</livre>
<livres>
</auteur>
<auteur nom="Brown" prenom="Dan">
<livres>
<livre>Anges et démons</livre>
<livre>Da Vinci Code</livre>
<livres>
</auteur>
</auteurs>
Ce type de fichier va passer par ce que l'on appelle un "parseur", il existe plusieurs méthode: DOM, Sax, SimpleXML... et presque tous les langages ont un parseur plus ou moins simple à utiliser.
Un des plus grands intérêts que propose XML est de pouvoir passer par un processus de validation de format. On utilise pour cela une DTD pour "Document Type Definition". Ce fichier va décrire comment remplir un fichier XML en bon et dut forme et permettra la vérification automatique depuis un programme.
Le XML est aujourd'hui très répandu et très apprécié pour sa lecture aisée et son sérieux en terme de validation de données.
Mais depuis quelques temps un autre format commence à marcher sur les pieds de XML. Moins strict, plus facile à gérer, le JSON est le format d'échange le plus utiliser pour les transferts de données de type "AJAX". Mais il commence aussi à empiéter le rôle de XML dans d'autres domaines.
Bien que le "J" de "JSON" veuille dire "Javascript", l'implémentation ne se limite pas à ce langage. PHP, Perl, Python, Java, C, C++... beaucoup de langage savent utiliser ce format.
L'intérêt numéro 1 est qu'il n'est pas strict du tout, on représente presque tout avec du JSON et il se transforme en objet ou en tableau dans presque tous les langages et ce sans rien avoir à faire... car on ne parse pas le JSON, on le transforme en variable de langage.
En fait, le JSON est simplement la réprésentation de données en une structure objet de type ECMA ou Javascript, reprenons l'exemple de notre bibiothèque:
{
auteurs: [
auteur:{
nom: "King",
prenom: "Stephen",
livres :[
{
titre: "La ligne verte"
},
{
titre: "Carrie"
}
]
},
auteur: {
nom: "Brown",
prenom: "Dan",
livres :[
{
titre: "Anges et démons"
},
{
titre: "Da Vinci Code"
}
]
}
]
}
Les accolades délimitent les objets, les crochets délimitent des tableaux de données, ainsi, "livres" est un tableau d'objets qui ont une propriété "nom". "auteurs" contient un tableau d'auteurs, "auteur" étant un objet qui contient un nom, un prénom, des livres...
Et du coup, ceci peut se transformer en JavaScript directement, ou en PHP, en C, en Java... En PHP par exemple, ce sont les finction json_encode et json_decode qui sont utilisées pour encoder et décoder.
Il suffit de donner en paramètre à ces fonctions soit la variable (tableau indexé ou objet PHP) soit la chaine à transformer en objet, et le tour est joué !
Par contre, plus de DTD ni d'attributs ! le format est simple mais tout est mis en propriétés d'objet. Autre soucis, et pas des moindres, la taille du JSON doit être limitée à ce que supporte le langage...
XML peut être effectivement parsé séquenciellement ce qui permet aux langages de traitements de pouvoir manipuler des flux de données relativement lourds. JSON doit entrièrement être parsé et transformer pour être utilisable dans le langage cible.
Alors comment choisir et qui est le plus fort des deux ? La réponse est "ça dépen !".
Si vous avez besoin de parser beaucoup de données, de valider les flot de données ou encore que vos besoins sont spécifiques à XML (Webservices, XSLT...) alors le XML est la meilleure technologie que vous puissiez trouver. D'autant que l'édition manuelle est plutôt facile à appréhender.
En revanche, si vous voulez faire du Ajax, passer des données atypiques ou non formées et que la validation du contenu n'est pas une priorité, alors le JSON est bien plus pratique et bien plus souple que XML.
Le choix vous appartient, mais gardez en tête que le XML est plus fiable, que le JSON est plus souple, que le XML est parsable alors que le JSON est une représentation de données qui sera transformée.
Pas de commentaire pour le moment
Trackbacks
Pour ajouter un trackback (retrolien) sur ce ticket, utilisez cette adresse: http://www.metal3d.org/index.php/trackback/default/tb?id=blog%2F253
