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 ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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.Envoyé par berceker united
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 !
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...
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:
- JSON-RPC, à comparer avec XML-RPC
http://en.wikipedia.org/wiki/JSON-RPC
- SOAPjr ou JSON-WSP, à comparer avec SOAP
http://en.wikipedia.org/wiki/SOAPjr
http://en.wikipedia.org/wiki/Jsonwsp
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.
Heu le human readable de XML ....
pour moi les deux on leur avantage et les deux on des domaines d'usage de prédilection.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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>
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
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.
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.
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 !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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>
Mes tutoriels
Avant de poster :
- F1
- FAQ
- Tutoriels
- Guide du développeur Delphi devant un problème
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.
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.)
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.
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.
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.
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.
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 écrirepour 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 - Visualiser dans une fenêtre à part
2
3
4
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 xml : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
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é.
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.
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
Répondre avec citation
Partager