Jusqu'où ira l'essor de JSON ?
Le nouveau format d'échange de données est-il en train de s'imposer face au XML ?

Le , par Hinault Romaric, Responsable .NET
Le XML (eXtensible Markup Language) avait été largement adopté en tant que format d'échange de données entre différents systèmes, plates-formes et organisations.

Depuis la sortie de JSON (JavaScript Object Notation), ce format d'échange plus simple est devenu populaire à tel point que les débats JSON vs XML se multiplient depuis quelques semaines.

Comme dans ce billet de blog de Karsten Januszewski, célèbre développeur ingénieur de Microsoft, qui ne se demande pas si, mais quand JSON l'emportera sur le XML.

Karsten Januszewski constate, à l'occasion d'une rétrospective sur les différents choix pris dans le cadre du développement d'un service de prototypage, que JSON a eu une ascension rapide, au vu par exemple de l'augmentation du pourcentage d'API et de services prenant en charge JSON par rapport au XML.

Pour lui, cette popularité de JSON est dûe à la légèreté et à la simplicité du format par rapport au format XML, mais surtout à la nature non typée des flux JSON qui sont parfaitement adaptés au JavaScript.

La nature non typée des flux JSON cadrerait avec la façon dont le Web lui-même fonctionne. Le Web n'aime pas les schémas, il n'aime pas que les choses soient rigides ou trop structurées estime Karsten Januszewski.

Néanmoins, il ne rejette pas le format XML. Au contraire, il trouve que le format fonctionne parfaitement avec les langages à typages forts ou pour la représentation des objets graphiques. Pour illustrer ses propos, Karsten Januszewski s'appuie par exemple sur les couples Java/XML dans Android et .NET/XAML dans Windows Phone pour la représentation des interfaces utilisateurs.

Mais la récente prise en charge de JSON dans le Framework .NET 4.0, qui vient résoudre le problème de sérialisation sur les serveurs - véritable casse-tête des développeurs - montre clairement pour Karsten Januszewski que JSON est en plein essor.

Source : « L'essor de JSON », billet de Karsten Januszewski

Et vous ?

Que pensez-vous de cet opinion Karsten Januszewski sur la simplicité de JSON ?

Comparer JSON et XML a-t-il un sens ? Les deux formats vous paraissent-ils complémentaires ou l'un s'imposera-t-il face à l'autre ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de xelab xelab - Membre éprouvé https://www.developpez.com
le 01/06/2011 à 10:43
Citation Envoyé par berceker united  Voir le message
Bonjour,

Comme pour Pignoufy, je découvre JSON ici. Par contre, cette article me fait rappeler à un précédent sujet concernant l'utilisation inadapté/abusif du XML. Pensez-vous que JSON permet justement de réajuster l'utilisation du XML ?

Pour ce qui est des échanges AJAX en tout cas, ça simplifie les choses. En PHP par exemple, on utilise json_encode et json_decode et hop on a nos objets/tableaux prêts pour le javascript côté client (où on utilisera JSON.parse par exemple) ou pour le traitement en php côté serveur.
Avatar de DrHelmut DrHelmut - Membre habitué https://www.developpez.com
le 01/06/2011 à 11:29
Bien qu'étant un gros noob n'ayant pas encore eu l'occasion d'implémenter du JSON sur un projet, je suis plutôt d'accord avec celles et ceux qui estiment qu'on ne peut pas vraiment les comparer et qu'ils ont chacun leur champ d'application.

Je trouve que sur le papier JSON a deux gros défaults :
- pas lisible facilement par un humain, là ou une structure xml arborescente permet facilement une analyze de flux par exemple. (Et un bon soft sait lire un xml de façon arborescente sans avoir à écrire des tabulations ni des retours chariots dans le fichier ^^)
- pas de validation du flux ni de typage des données...

Après, il est clair que pour les webservices, ça ne peut être que plus performant que via SOAP, mais offre-t-il autant de possibilité ?
Quid d'un envoie/réception de flux binaire avec JSON ??

Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !
Avatar de stundman stundman - Membre à l'essai https://www.developpez.com
le 01/06/2011 à 13:01
Moi aussi je pense que ça n'a pas la même utilisation.

Le JSON va très bien pour faire de l'AJAX où les échanges serveur/client doivent être limités en taille. Il est donc très bien pour le développement d'applications d'échange de données. C'est aussi surtout un langage de tâche de fond, et incompréhensible si on n'est pas averti.

Le XML est pour moi le standard qu'il faut continuer d'utiliser. Il est lu par les applications de bureau (Excel, Calc d'OpenOffice), on peut facilement comprendre la structure et le contenu, il est lisible par les navigateurs, on peut aussi l'interfacer avec des feuilles de style XSL pour en faire une page web. Il possède des librairies capables de développer sur tous les langages facilement, et de plus en plus d'applications de traitement de données l'utilisent comme format d'entrée.

Et sinon, il y a YAML qui lui aussi se positionne entre les deux. Mais comme il est n'est pas utilisé par le web, on l'oublie...
Avatar de =JBO= =JBO= - Membre émérite https://www.developpez.com
le 01/06/2011 à 13:17
Citation Envoyé par DrHelmut  Voir le message
Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !

Tu ne peux pas comparer XML et SOAP car le niveau d'abstraction est bien différent...
Pour la même raison, la comparaison entre JSON et SOAP n'est pas possible.

JSON est un substrat pour des protocoles alternatifs:

Avatar de robynico robynico - Futur Membre du Club https://www.developpez.com
le 01/06/2011 à 15:29
Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !
Avatar de zeyr2mejetrem zeyr2mejetrem - Membre chevronné https://www.developpez.com
le 01/06/2011 à 16:23
Citation Envoyé par robynico  Voir le message
Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !

Si tous les nains de jardin du monde se donnaient la main, les brouettes tomberaient sur le côté.

Sérieusement, je pense qu'aucun des formats n'est mauvais en soi. L'implémentation qui en est faite dans un contexte donné peut l'être.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 01/06/2011 à 19:30
Heu le human readable de XML ....
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
<PID> 
  <PID.1>1</PID.1> 
  <PID.3> 
     <CX.1>PATID1234</CX.1> 
     <CX.2>5</CX.2> 
     <CX.3>M11</CX.3> 
     <CX.4><HD.1>ADT1</HD.1></CX.4> 
 
     <CX.5>MR</CX.5> 
     <CX.6><HD.1>MCM</HD.1></CX.6> 
   </PID.3>
pour moi les deux on leur avantage et les deux on des domaines d'usage de prédilection.

Mais cela n'empêche pas de se poser la question du choix
car contrairement à ce qui a été dit JSON est lui aussi tout comme XML un format validable et instrumentable.

on a donc an JSON des capacités comparable schémas RPC WS etc.

ce qui les différencie profondément c'est l'outillage JSON plus jeune est moins bien outillé et surtout pas complètement normalisé pour beaucoup de chose.

reste donc à savoir ce que l'on veut en faire. si je prends quelques exemple ou le réflexe du développer java sera de choisir XML se poser la question peut ouvrir des horizons.

par exemple je croise souvent dans des appli java des mécanisme de sérialisation xml d'objet soit pour se les échanger soit pour les conserver dans des fichiers.
cela demande un sérialiseur et un parser qui accepte un schéma et c'est tout chose qu'on a à l'identique avec JSON
oui la techno sur se point est nouvelle mais elle offre des avantage non négligeable à surveiller donc.

autre exemple que j'ai croisé récemment des fichier de conf dans une appli C++ qui étaient autre fois en xml et aujourd'hui en Json. avantage léger facile à lire et à éditer structuré évolutif

maintenant je dois reconnaître à xml sa maturité et dans de très nombreux cas Il a fait ses preuves.
et je l'utilise énormément.

Je pense que leurs domaines de prédilection sont distinct mais il y a des zone de recouvrement.

les comparer et une bonne chose et continuer à le faire aussi.

J'espère que JSON gardera son approche très pragmatique.

A+JYT
Avatar de selenith selenith - Nouveau membre du Club https://www.developpez.com
le 01/06/2011 à 19:41
Ayant pas mal utilisé les deux, je ne peux que confirmer ce qui a été déjà été dit : utilisé JSON plutôt que XML, ou l'inverse, dépend de ce qu'on a besoin et du contexte dans lequel on se trouve.

Par contre pour ceux qui veulent vraiment de la légèreté a l'extrême il existe un autre format inspiré du XML mais linéaire dans l'écriture et dans la conversion: SimBa.

On y perd la possibilité d'arborescence mais on y gagne en efficacité de traitement.
Avatar de popo popo - Membre expérimenté https://www.developpez.com
le 01/06/2011 à 19:51
Personnellement, je ne connais pas non plus JSON mais quand je lis ce que me renvoie Google sur le sujet, je remarque un sérieux désavantage par rapport à XML : Il ne convient pas pour des ressource de taille importante !

Et puis si JSON devient plus populaire que XML, j'aimerai pas être à la place de microsoft. Pour rappel, les fichiers de microsoft office sont en réalité des fichiers XML. En renommant un fichier docx en zip et en regardant à l'intérieur de l'archive on s'en aperçoit très bien.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
<PID> 
  <PID.1>1</PID.1> 
  <PID.3> 
     <CX.1>PATID1234</CX.1> 
     <CX.2>5</CX.2> 
     <CX.3>M11</CX.3> 
     <CX.4><HD.1>ADT1</HD.1></CX.4> 
 
     <CX.5>MR</CX.5> 
     <CX.6><HD.1>MCM</HD.1></CX.6> 
   </PID.3>
OK, c'est pas très lisible mais je serais curieux de voir ce que ça donnerai en JSON. Pas sur que ce soit plus lisible !
Avatar de thelvin thelvin - Modérateur https://www.developpez.com
le 02/06/2011 à 18:50
Citation Envoyé par marts  Voir le message
A mon avis, rien de ce que permet le XML n'est impossible avec JSON.

Ce n'est pas une question d'avis, tu te trompes.

- JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)

- JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.

On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.

Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.

Citation Envoyé par sekaijin  Voir le message
Heu le human readable de XML ....
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
<PID> 
  <PID.1>1</PID.1> 
  <PID.3> 
     <CX.1>PATID1234</CX.1> 
     <CX.2>5</CX.2> 
     <CX.3>M11</CX.3> 
     <CX.4><HD.1>ADT1</HD.1></CX.4> 
 
     <CX.5>MR</CX.5> 
     <CX.6><HD.1>MCM</HD.1></CX.6> 
   </PID.3>

On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 03/06/2011 à 12:28
Citation Envoyé par popo  Voir le message
Personnellement, je ne connais pas non plus JSON mais quand je lis ce que me renvoie Google sur le sujet, je remarque un sérieux désavantage par rapport à XML : Il ne convient pas pour des ressource de taille importante !

heu 2Go de données dans un fichier JSON ...
T'es sur de ce que tu avance ?
Je ne connais aucune limitation en taille à JSON
la seule que je connaisse n'est pas du à JSON outils tout comme avec XML si tu utilise DOM il te faut mettre les objets en mémoire et tu en deviens dépendant. Par contre on ne trouve quasiment pas de parser type SAX (de xml) c'est à dire au fil de l'eau. mais aucun limitation dans le format si ce n'est la taille des supports.

Citation Envoyé par popo  Voir le message
Et puis si JSON devient plus populaire que XML, j'aimerai pas être à la place de microsoft. Pour rappel, les fichiers de microsoft office sont en réalité des fichiers XML. En renommant un fichier docx en zip et en regardant à l'intérieur de l'archive on s'en aperçoit très bien.

je ne vois pas en quoi cela remets en cause ce choix XML est un bon choix et même si JSON devient populaire il le restera.

Citation Envoyé par thelvin  Voir le message
- JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)

Là j'avoue ne pas comprendre. je ne vois aucune raison qui empêche d'utiliser JSON à la place de ces flux c'est même se que je fais je n'utilise plus HTML mais JSON est mon moteur de rendu lit des flux JSON bien plus concis et léger.

Citation Envoyé par thelvin  Voir le message
- JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.

Là encore je ne comprends pas. XML c'est des symboles <> = " organisé et des string rien de plus XML n'est pas plus extensible que JSON. si tu entant par extensible qu'on peut mettre dans un XML la balise de son choix, il en va de même en JSON ou tu peux ajouter le membre de ton choix. si tu entends par là qu'un peut inclure dans XML d'autre XML c'est pareil en JSON. la seule différence entre les deux c'est qu'en XML tu a une norme (deux en fait) pour typer plus fortement ton XML.

Citation Envoyé par thelvin  Voir le message
On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.

Les entity sont un pi aller créer pour XML à fin de pouvoir inclure les éléments non supporté par le flux. le seul qu'on ne peut pas utiliser en JSON est " pour cela on a été obligé d'introduire \ du coup pour mettre \ il faut mettre \\ à quoi servent les entity dans un pareil cas ?
pour les référence c'est effectivement un choix de JSON de ne pas mettre utiliser les références JS dans un flux
mais XML fait de même. je ne peux pas écrire
Code xml : Sélectionner tout
1
2
3
4
<user> 
  <name>Dupond</name> 
  <id>user.name</id> 
</user>
pour désigner dans la valeur de mon id l'élément name de user user.name ou tout autre forme n'est qu'une chaîne de caractère et non une référence. avec XML je vais pouvoir créer une string qui est le chemin vers l'élément de mon choix.
Code xml : Sélectionner tout
1
2
3
4
<user> 
  <name>Dupond</name> 
  <id>/user/name</id> 
</user>
XML n'interprétera l'élément id que comme une chaîne. il faudra ajouter une passe supplémentaire d'interprétation XPATH pour résoudre les références et obtenir Dupond dans le champs id. avec JSON on est exactement dans la même situation.
Code javascript : Sélectionner tout
1
2
3
4
"user":{ 
  "name" :"Dupond", 
  "id":"user.name" 
}
JSON fera de l'élément id une string contenant le chemin et il faudra une passe d'interprétation de cette chaîne pour obtenir Dupond
la différence entre JSON est XML sur ce point est encore une fois que la façon de décrire le chemin est normalisé. en JSON on utilise soit la notation pointé de javascript soit les sélecteurs CSS mais rien de normalisé.

Citation Envoyé par thelvin  Voir le message
Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.

La encore tu te trompe lourdement. XML ne permet rien de plus que JSON Les outils XML sont disponible et normalisé ceux de JSON non. encore une fois XML n'est que format autour de lui gravitent des normes et des outils les implémentant. pour XSLT par exemple rien de plus simple à faire en JSON t fais un JSON qui définit le pattern en utilisant la syntaxe sélecteurs css3 et le résultat à obtenir en JSON le moteur s'écrit en quelques lignes de JS.
Mas question est simplement pourquoi le faire lorsqu'avec XML on a déjà les outils. il faut savoir être pragmatique et évaluer l'usage avant le format de support. je pense que des moteurs de transformations arriverons dans le monde JSON que si dans l'ensembles des point à évaluer qui font qu'on choisit se format seul ou persque la transformation est absente. si dans ton dev tu fait deux colonne et pour chaque critères tu mets des points à XML ou a JSON et qu'au final tu as 80% pour JSON et qu'il te manque une fonctionnalité dans JSON tu va l'implémenter. et si tu obtients 80 en faveur de XML et qu'il ne manque une fonctionnalité supporté par JSON tu vas aussi l'implémenter en XML. ça ne change rien.

Citation Envoyé par thelvin  Voir le message
On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)

C'était une boutade pour l'argument sur la lisibilité. pour moi XML dès sa définition à voulu pousser vers le "Human Readable" mais nous sommes tous face à des choix et il arrive souvent que le meilleur choix même en XML ne soit pas "Human Readble". face à ça JSON à pour sa part cherché à sa naissance à être "Machine Readable" mais transportable en string. et nous sommes ainsi fait lorsque nous choisissons des nom nous les choisissons de préférence lisible par nous. du coup JSON à parcouru le chemin inverse.
Au final je dis que mettre dans la balance lorsqu'on doit choisir entre JSON et XML le fait que XML est "Human Readable" je réponds que ce n'est pas recevable.

pour moi il existe des point bien plus fondamentaux dans les différence entre XML et JSON si je dois mixer deux structures de données en XML je peux utiliser les namespaces et la norme comme les outils me garantissent une claire distinction. je n'ai rien de tel en JSON ou par définition de base tout est faiblement typé. se sera à moi développeur de garantir cette distinction.
ce n'est pas impossible ce n'est pas difficile est juste à faire.
il existe des contextes d'utilisation où la distinction entre attribut et élément est un plus important. (je ne connais pas de cas où on ne peut s'en passer
uniquement des cas ou ça rends les chose beaucoup plus claires et faciles) dans ces cas là XML m'offre cette distinction alors que JSON non. là encore ce n'est pas insurmontable, ce n'est pas difficile mais c'est à moi développer de le faire.

A+JYT
Offres d'emploi IT
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)
Architecte électronique de puissance expérimenté H/F
Safran - Ile de France - Villaroche - Réau
Architecte systèmes études & scientifiques H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil