je ne dis pas que je ne l’aime pas, juste qu’il est utilisé à tort et à travers pour n’importe quel usage qui n’y est pas adapté.

Alors parlons objectif et factuel. Comme j’ai l’impression que c’est ta réponse qui est dans l’affectif je vais tenter d’en dépiler le contenu pour le discuter sur des faits.

– JSON n’est pas fait pour être validé ? C’est toi qui le dit. Personnellement je ne vois pas de raison pour laquelle telle ou telle grosse boite pourrait avoir envie de valider les flux venant des API Facebook par exemple.

Mais soit. Acceptons. Tu viens de retirer un usage au JSON là où XML passe bien.

– JSON est un format de sérialisation et non de description ? Je ne sais pas bien s’il y a une différence fondamentale vu que ce que tu sérialises c’est bien la description d’une donnée. Pour ma part json.org parle de « format d’échange », ce qu’est aussi XML.

Mais soit, acceptons. Tu viens de retirer un usage au JSON mais comme XML est utilisé depuis des années pour faire de la sérialisation, je ne vois toujours pas d’usage avantageux pour le premier.

– Il ne faut pas faire la validation sur le document mais sur l’objet au final ? J’en suis étonné vu que l’objet de la validation des messages c’est généralement d’éviter d’injecter des erreurs dans le code et d’arriver à l’objet avec des données malformées, ou au moins de pouvoir vérifier que l’erreur vient du document et pas du code objet.

Mais soit, acceptons. Avec quoi fais tu cette validation de l’objet ? tu as des outils ? des standards ? des façons de faire classiques ? des aides ? Si tu me dis qu’il s’agit de refaire une roue spécifique à chaque fois tu ne fais que donner de l’eau à mon moulin.

– Sur JSON on n’écrit pas de schéma mais de la documentation ? J’en suis étonné. Les deux ont des objectifs différents qui ne se recoupent aucunement et qui ne sont pas exclusifs. L’un n’a jamais remplacé l’autre.

Mais soit. Là aussi tu viens de retirer un usage du JSON mais je pense que tu accepteras que rien n’empêche de faire de la doc pour du XML donc là non plus je ne vois pas trop l’avantage.

Pour la lisibilité c’est effectivement purement subjectif mais quand il y a plein d’accolades fermantes et que les ouvrantes ne sont pas devant les yeux, il est souvent difficile de savoir où on en est. Ce n’est pas propre à JSON, les codes de programmation sont bien les mêmes. On trouve d’ailleurs plusieurs guides de style de programmation qui recommandent de mettre des commentaires en face des accolades fermantes pour repéter l’instruction d’ouverture histoire de s’y retrouver.

Ceci dit je prends le point, c’est effectivement subjectif.

Pour la lib dédiée oui, json_encode existe depuis PHP 5.2 donc encore inaccessible pour une grande partie des installations (entre autres toutes les Redhat entreprise). En Ruby par exemple c’est du code utilisateur et il y a plusieurs implémentations. En javascript je crois que j’en parle dans le corps de l’article.

Mais parlons objectivement vu que ce que tu dis globalement c’est « oui, mais ce que ça ne fait pas ce n’est pas fait pour » alors .. c’est quoi les usages pour lesquels JSON est adapté et que XML ne fait pas mieux ou au moins à peu près aussi bien ? À part les premiers usages dont je parle dans la dernière section de ce billet, je ne vois pas bien.