JSON: Un nouveau format, explications

Mike Chambers vient de publier un tutorial très complet et accessible (il présume que vous ne connaissez rien à Flex/Flash) sur l'utilisation de la librairie opensource corelib (écrite par Darron Schall) nécessaire pour travailler avec des données au format JSON. L'occasion est idéale pour faire le point sur ce nouveau format d'échange de données.

Qu'est-ce que JSON?

Voici la traduction de la définition du site officiel:

JSON (JavaScript Object Notation) est un format d'échange de donnée caractérisé par un faible poids de fichier. Il est facile d'accès, tant pour la lecture que pour l'écriture, pour les développeurs. Alors que les ordinateurs bénéficient également d'aisances quant à son utilisation et sa génération. Ce format est basé sur sous-ensemble du JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON est un format texte qui est totalement indépendant d'un langage en particulier. Cependant, ils comportent des conventions qui seront familièrent aux développeurs de la famille des C (C, C++, C, Java, JavaScript, Perl, Python, etc.). Toutes ces caractéristiques font de JSON un format idéal pour l'interopérabilité des données.

Soulignons entre autres que JSON a beaucoup été mis à l'honneur ces derniers temps grâce à l'explosion d'Ajax. Une solution de transfert de données rapide en processing et possédant un coup faible en terme de bande passante devenant alors une nécessité (voir une obligation).

Un remplacant du XML (The Fat-Free Alternative) ?

En effet, l'amalgame "Echange de données / XML semble trivial.

La conclusion du JDN Développeurs dans son article consacré à JSON, se résume plus ou moins à dire que le XML conserve ses avantages propres (à l'instar de son extensibilité) alors que JSON offre une nouvelle alternative convenant parfaitement à des applications internets nécessitant des transferts légers (sans être péjoratif).

Alors que le site officiel se montre bien entendu un peu plus critique (partial?) et surtout plus approfondi dans sa comparaison. Ce prétendu avantage de l'extensibilité est par exemple mis à mal par le simple fait que JSON n'a pas à l'être. Il ne s'agit aucunement d'un document markup language.

J'en retiens que la principale distinction à faire est justement que JSON n'est pas un langage balisé. De ce fait, il est fait pour manipuler des données (avec tout ce que cela implique) et non des documents comme en est capable XML ( XML is document-oriented. JSON is data-oriented.). Au développeur de faire le bon choix en fonction de son application.

Use the right tool for the right job.

Exemples

Voir le site.

Liens connexes

neolao - JSON: Ne manquez pas de lire les commentaires, surtout le passage sur la librairie Eden écrite par Zwetan. Qui comme il tient à préciser: C'est proche de json mais ce n'est pas comme json ni même inspiré de json.

Commentaires

1. Le mercredi, mars 29 2006, 09:36 par ekameleon

Hello :)

JSON nouveau ? ;) Pas tant que cela en fait... tout le monde en parle en ce moment avec AJAX mais de là à dire que c'est nouveau ! ;)

Si je peux me permettre je vais en profiter pour parler un peu de ma version de la classe JSON (compatible complètement à priori avec MTASC) et de son utilisation dans ASGard avec la classe JSONLoader, je ferais un tuto là dessus dans pas longtemps mais tout est déjà en ligne :

- la classe JSON AS2

- la classe JSONLoader AS2 qui fonctionne sur un modèle très proche du framework AS3 actuel (voir classe URLLoader, URLRequest et URLVariables)

EKA+ :)

2. Le mercredi, mars 29 2006, 10:58 par Shaoken

Effectivement, le nouveau est à nuancer. Je l'avais d'ailleurs mis exprès entre apostrophes mais ca ne resort pas assez ;) Par contre, je suis assez étonné du peu de connaissance de ce format.

Très intéressantes ces classes. Je dois définitivement jeter un coup d'oeil sur tes derniers packages.

++ :)

3. Le mercredi, mars 29 2006, 11:32 par dvil

C'est chouette de lire que c'est léger. Mais c'est léger "combien" par rapport à XML ? Est-ce qu'il y a des chiffres de comparaison ?

Sinon, ben oui c'est bien et j'vais y jeter un peil plus pratique. Cela dit je n'ai pas l'impression que c'est un truc bien "malin" ou bien "nouveau" non plus.. Rhaaa, l'Internet ou le paradis des fausses nouvelles nouvelles nouvelles technologies dans ta face ;)

4. Le mercredi, mars 29 2006, 12:33 par ekameleon

@dvil > regarde ta structure xml et la structure que tu peux en faire au niveau JSON... tu vas vite voir la différence ^_^ sur le site de JSON tu as des exemples.

Le XML est à la mode mais il demande d'utiliser des tas de caractères inutiles pour pas grand chose.. et ensuite quand tu utilises le parser de FLASH, qui est d'une lenteur pas possible, faut penser à retransformer ton XML en tableau d'objet ou autre, alors que JSON le fait directement et plus finement vu que tu as accés à des données de type Number, Array, Object, String... le XML cela reste uniquement du String à la sortie.

5. Le jeudi, mars 30 2006, 15:59 par dvil

Oh mais loin de moi le négativisme (j'espère que tu ne crois pas ça). Je trouve ça très bien.. Je me dis juste que ce n'est pas super malin parce que sans connaître "json", j'avais déjà fait des essais dans ce sens pour formater des entrées vers un swf. Et comme je ne prétends pas être un développeur aguerri, j'avais pas eu l'idée d'appeler mon idée une révolution. Ca me semblait aller de soi de reprendre des déclarations littérales d'objets, de tableaux ou de variables pour injecter dans flash. Après tout, xml est peu satisfaisant parce qu'il oblige à dé-formater, re-formater et l'url-encoded est franchement idiot pour des données structurées.. Donc voilà, je m'étais dit, en son temps.. Mais c'était il y a longtemps, parce que j'suis vieux hein ;-)

Pour ce qui est de ma question, je me demandais juste très honnêtement si il existait des comparaisons. Intuitivement, je me rends bien compte que Json est moins verbeux que xml.. Je me demandais juste s'il existait des chiffres pour développer l'argument qui dit que "c'est mieux parce que c'est plus léger". Vieille habitude de scientifique qui a besoin de concret. Toutes mes excuses ;-)

6. Le jeudi, mars 30 2006, 19:10 par ekameleon

Les benchs c'est bien ... mais le mieux à mon avis c'est tout simplement de l'essayer au moins une fois pour voir ;) C'est si rapide et si simple qu'à mon avis rien que là cela suffit pour se faire une idée précise de la chose.

Enfin .... je dirai tout de même que cela vaut le coup pour débuter lol Mais aprés vaut mieux utiliser EDEN à mon avis.

7. Le vendredi, mars 31 2006, 12:21 par tommy

Ca m'a l'air intéressant, surtout si on peut l'utiliser de php vers flash et ainsi transmettre des objets complexes autrement plus facilement que par loadvars. Merci pour ton article :D

8. Le vendredi, mars 31 2006, 12:23 par ekameleon

Le top avec le PHP c'est de le coupler avec AMFPHP et de stocker les chaines JSON directement dans la base de donnée :) Du coup on profite du parsage binaire d'AMFPHP et de la souplesse de JSON pour retrouver certains objets :) Il est vrai que AMFPHP permet de sérialiser les objets natifs de flash mais dans l'idée d'utiliser EDEN .. il est tout de même vraiment sympatique d'imaginer qu'il devient possible de sauvegarder dans une base de donnée un objet personnalisé de façon super souple.

shaoken