Discussion:JavaScript Object Notation

Autres discussions [liste]

Admissibilité
Neutralité
Droit d'auteur
Article de qualité
Bon article
Lumière sur
À faire
Archives
Commons

Cet article est indexé par le projet Informatique.

Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.

**Évaluation** de l’article « **JavaScript Object Notation** »
Avancement	Importance	pour le projet
Bon début	Faible		Informatique (discussion • critères • liste • stats • hist. • comité • stats vues)

Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.

Quelle différence entre "évaluer une expression JSON" et "parser la même expression JSON" ? si "evaluer" et "parser" ont le meme sens, alors la derniere phrase se contredit: "a peu pres aussi efficace en temps de traitement, par contre c'est plus long" - pulse 15/8/2008

Pas dans ce contexte: ici évaluer signifie utiliser la fonction eval() qui EXECUTE l'objet JSON comme si c'était un programme javascript, alors que PARSER signifie qu'on va lire le fichier et le convertir manuellement.
Si on prends comme exemple un fichier .bat windows, on aurait avec un fichier :

echo "ca marche"
exec code malveillant

"évaluer" reviendrais à double cliquer sur le .bat pour le faire exécuter par windows (et donc exécuter le code malveillant
"le parser" reviendrais à lire le fichier, rechercher tout "echo texte" et afficher le texte, en ignorant le reste non voulu, c'est plus long mais plus sûr (a moins que le code ne sois déjà sûr de ne pas contenir de code malveillant de base) Keul (d) 27 janvier 2009 à 13:26 (CET)[répondre]

Rappelons que 'to parse' signifie analyser en français. En général pris au sens d'une analyse syntaxique ; prendre un code source et en faire quelque chose, en l'occurence me semble-t-il transformer un texte json en un objet interne au moteur javascript.

sécurité[modifier le code]

dans sa technique usuelle JSON est sur j'ai mis une petite explication mais je sais pas si elle est claire. Xavier Combelle (d) 12 juillet 2013 à 19:32 (CEST)[répondre]

Inconvénient??[modifier le code]

Pour une étude de coût de migration, je viens de me renseigner sur cette technologie, sur plusieurs forums, et sur wikipedia. Je trouve que l'article est peu objectif et très optimiste : dans le cas du B2B (dans notre cas, deux appli java qui communique), je lui vois peu d'avantage sur une solution xml+soap classique, et même plusieurs inconvénient !! Par ailleurs, certains avantages sont largement exagérés (du XML est aussi simple à lire sinon plus, que les objets JSON que j'ai pu voir) .

Bref, je reconnais que la technologie parait très adapté à du client-serveur.....mais de là à remplacer tout et à ne lui trouver que des avantages ....

Un section inconvénient serait donc bienvenu (je laisse ceci à ceux qui ont plus d’expérience que moi dans cette technologie !!)

Il y a une section "inconvénient" qui est déjà présente. Elle indique les inconvénients, mais elle ne fait pas de comparatif avec les autres solutions possibles. Il existe un tel foisonnement de technologie (et de société d'éditeurs dans le W3C !) qu'il serait difficile d'aborder ce sujet. Et surtout, il serait impossible de mettre à jour l'article au fur et à mesure de l'évolution des technologies.

Dans votre cas particulier, vous vouliez comparer à SOAP : voir (en) Pourquoi utiliser XML(SOAP) quand JSON est moins ardu et SOAP vs REST vs JSON comparison 2018.

JSON est utilisé par AJAX, les services Web et Ansible.

Discussion utilisateur:Romanc19s (discuter) 21 octobre 2018 à 13:21 (CEST)[répondre]