Discussion :

[Stéphane le calme]

ECMA International adopte JSON comme standard,
le format d'échange de données continue son ascension

JSON (JavaScript Object Notation) a été adopté comme standard ECMA suite à un vote de l'Assemblée Générale. Cette nouvelle norme s'est vue attribuer le numéro 404, ce qui ne manque pas de rappeler celui du code d’erreur du protocole de communication HTTP sur le réseau Internet, renvoyé par un serveur HTTP pour indiquer que la ressource demandée (généralement une page web) n’existe pas.

Rappelons que JSON se base sur deux types de structures de données :

• une collection de couples nom/valeur. Divers langages la réifient par un objet, un enregistrement, une structure, un dictionnaire, une table de hachage, une liste typée ou un tableau associatif ;
  
• une liste de valeurs ordonnées. La plupart des langages la réifient par un tableau, un vecteur, une liste ou une suite.

Parmi les avantages qu'offre ce langage, nous pouvons citer :

• la simplicité de la mise en œuvre ;
  
• la lisibilité du code ;
  
• sa syntaxe réduite et non extensible qui facilite l'apprentissage ;
  
• des types de données connus (objets, tableaux, valeurs génériques de type tableau, objet, booléen, nombre, chaîne ou null).

Bien que basé sur JavaScript, JSON est complètement indépendant de tout langage de programmation. Toutefois, les conventions qu'il utilise seront familières à tout programmeur habitué aux langages descendant du C (C, C++, C#, Java, JavaScript, Perl, Python etc). Par exemple un tableau commence par "[" (crochet gauche) et se termine par "]" (crochet droit). Les valeurs sont séparées par "," (virgule).

Il sert à faire communiquer des applications dans un environnement hétérogène. Il est notamment utilisé comme langage de transport de données par AJAX et les services Web. Il peut aussi être utilisé pour la sérialisation et désérialisation d’objets ou l’encodage de documents. Des bibliothèques pour JSON existent dans la plupart des langages de programmation.

Source : ECMA-404 (au format PDF)

Et vous ?

Avez-vous déjà utilisé JSON ? Qu'en pensez-vous ?

Avez-vous déjà utilisé un autre format d'échange de données ? Si oui lequel ?

[Traroth2]

J'ai déjà utilisé JSON, dans un contexte REST, mais pas seulement. Et j'ai aussi utilisé différents formats basés sur XML, comme SOAP.

JSON est plus compact, il est plus orienté vers la sérialisation d'objet (j'ai parsé du JSON avec JsonPath, et j'avais l'impression de commettre un pêché mortel ), et de par ses origines, clairement orienté Javascript (ce qui peut en fait avoir un intérêt assez limité, par exemple si on fait un appel Rest d'un serveur Java à un autre). C'est une alternative intéressante à XML, mais ça ne change pas la face du monde. Je le trouve un peu moins évident à lire par un humain, mais c'est peut-être personnel (c'est la salade d'accolades et de crochets qui me dérange)

[flow10000]

Il était temps, cette nouvelle me réjoui

[jhenaff]

J'espère juste qu'ils intégreront la notion de commentaires "/* */" dans la norme.
C'est le seul point négatif du JSON pour le moment vu qu'on ne peut pas commenter les data...

[ejorge]

JSON/BSON est aussi pas mal utilisé dans le nosql (big data pour employer des gros mots).

[air-dex]

Avez-vous déjà utilisé JSON ? Qu'en pensez-vous ?

Je l'ai déjà utilisé et je le trouve lisible.

Bien que basé sur JavaScript, JSON est complètement indépendant de tout langage de programmation.

C'est vite dit. JSON est aussi régi par la spécification RFC 4627. On y trouve le passage suivant :

Generally there are security issues with scripting languages. JSON is a subset of JavaScript, but it is a safe subset that excludes assignment and invocation.

A JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all the characters not enclosed in strings are in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.

JSON est donc censé être particulièrement interopérable avec JavaScript et donc sa célèbre gestion des entiers à 64 bits. Cela amène des joyeusetés comme celle de ce bug de Qt dont la résolution est entravée par ces considérations là. Paye ton indépendance !

[Bylon]

JSON est donc censé être particulièrement interopérable avec JavaScript et donc sa célèbre gestion des entiers à 64 bits. Cela amène des joyeusetés comme celle de ce bug de Qt dont la résolution est entravée par ces considérations là. Paye ton indépendance !

Je ne vois pas ce que a à voir avec la RFC4627 !
C'est un bug de QtJSON, pas de JSON.

La "norme" ne précise absolument pas de longueur limite aux nombres.
A la limite on pourrait dire que ça mériterait d'être précisé, sinon ça devient "parser-dépendant"... à moins qu'on utilise un parser-mode-sax avec des callbacks, auquel cas c'est à l'utilisateur de la librairie de se débrouiller avec la longueur/précision des nombres.

Du reste, pour ce qui est des nombres, la norme JSON est assez étrange.
Elle autorise des choses qui n'ont pas trop de sens comme :
0.0E+27

Mais interdit des notations que 99.9% des langages acceptent comme :
.2

JSON présente aussi un inconvénient par rapport à des choses mieux normalisées comme XML : il y a de l'implicite.

Par exemple sur le codage utilisé.
En réalité il n'est pas "explicité" comme en XML où on doit indiquer "encoding".

Certes la norme dit que ça doit être de l'UTF, et donne un moyen de "deviner"... mais tout ça reste alors empirique. Et tout ce qui n'est pas clairement explicité (par exemple avec "encoding") finit un jour ou l'autre par vous péter à la figure !..

Sinon, à part ça, JSON est sympathique par sa compacité... comme par la compacité de sa norme qui la rend facile à implémenter.

[yimson]

J'ai utilisé JSON seulement dans un contexte académique.
Je souhaite vraiment mettre en œuvre ce langage dans
un réel projet Web services. Si vous avez des documents
ou même des liens, à me conseiller dans ce sens alors
je suis preneur.

[deltree]

*Avez-vous déjà utilisé JSON ? Qu'en pensez-vous ?
J'utilise JSON dans tous les service REST en web service java/javascript.
je le trouve aussi super pratique comme configuration de programme Javascript.
Pour moi c'est le successeur de XML qu'il pourrait remplacer à tous les niveaux: configuration et transport de données.

*Avez-vous déjà utilisé un autre format d'échange de données ? Si oui lequel ?
J'utilise aussi le YAML, qui se transforme bijectivement en JSON.
Pour ceux qui sont allergiques aux {*de javascript, YAML c'est en gros du JSON sans les accolades.

[sekaijin]

Nous avons adopté JSON comme représentation d'un Objet sous forme de String en JAVA

Pour les classes de nos frameworks, la méthode toString retourne une représentation JSON. Cela offre de la souplesse lorsqu'on souhaite inspecter un objet.

Nous avons aussi adopté ce format pour JMX. Nos méthodes exposées en JMX retournent des fragments JSON. Du coup lorsqu'on utilise un outil de base pour accéder à une méthode, on obtient quelque chose d'humainement lisible (même si c'est gros) et on peut le traiter lorsqu'on y accède via un utilitaire spécifique.

par contre pour moi JSON ne replace pas XML. même si les deux on des dommaine d'usage qui se recouvre les deux on aussi des dommaines disjoints.

Pour moi JSON est un format structuré faiblement typé. XML est lui équipé pour définir des contraintes de type bien plus fortes. Suivant le besoin l'un ou l'autre à l'avantage.
De même dans le transport d'information si le besoin est un transport simple sans transformation. JSON est intéressant, car simple et léger. Il offre l'avantage d'être souple. Mais nécessite de toujours vérifier la présence des éléments attendus dans l'échange. XML lui permet de contraindre le format et de garantir que l'échange est conforme à une structure précise. Il offre l'avantage de disposer de nombreux outils de transformation.



A+JYT

[air-dex]

Je ne vois pas ce que a à voir avec la RFC4627 !
C'est un bug de QtJSON, pas de JSON.

Je sais bien. C'est juste que ceux devant résoudre le bug se planquent derrière cette RFC pour justifier sa non correction (à tort). Les motifs invoqués sont du style "JSON n'a pas à traiter les entiers longs de 64 bits [à cause du JavaScript] donc ce n'est pas un problème", le tout avec la RFC pour justifier leurs propos. C'est bête mais c'est la réalité de la résolution de ce bug de Qt.