Pour parser du JSON vers une structure native au langage (généralement dictionnaire ou objet anonyme + liste), c’est à peu près une ligne de code de type json_decode dans quasiment tous les langages, le plus souvent intégré dans la lib standard. Pour RSS/Atom c’est déjà plus compliqué, surtout que chacun de ces deux formats a plusieurs version. Et à l’intérieur d’une seule version d’un format tu as des subtilités peu intéressantes que je ne veux pas me trimballer d’un bout à l’autre du pipe (par exemple la différence entre publication date, creation date et modification date: typiquement un truc que le producteur veut abstraire pour simplifier tout le reste de la chaine de traitement).
Niveau production, le JSON est tout aussi simple, un json_encode d’une structure langage du standard (la même que json_decode) et c’est plié.
Par comparaison avec RSS/Atom, dans la plupart des langages dans la lib standard tu as au mieux une API type DOM pour faire du XML. Et lire/produire du RSS/Atom à partir d’une simple API type DOM, ce n’est certes pas la fin du monde, mais c’est infiniment plus compliqué et ce n’est certainement pas quelque chose que tu veux refaire n fois un dans un projet composé d’une multitude d’exécutables différents et indépendants et même écrits dans des langages différents.
tl;dr: haters gonna hate, mais aujourd’hui en 2014 JSON a gagné haut la main et c’est LE langage d’interopérabilité par excellence. On ne devrait plus justifier l’utilisation de JSON mais bien plutôt sa non-utilisation, et dans le cas de la non-utilisation la justification devrait être solide.
[^] # Re: Intérêt du JSON
Posté par Moonz . En réponse à la dépêche Publication de UA (Universal Aggregator). Évalué à 8.
Pour parser du JSON vers une structure native au langage (généralement dictionnaire ou objet anonyme + liste), c’est à peu près une ligne de code de type
json_decodedans quasiment tous les langages, le plus souvent intégré dans la lib standard. Pour RSS/Atom c’est déjà plus compliqué, surtout que chacun de ces deux formats a plusieurs version. Et à l’intérieur d’une seule version d’un format tu as des subtilités peu intéressantes que je ne veux pas me trimballer d’un bout à l’autre du pipe (par exemple la différence entre publication date, creation date et modification date: typiquement un truc que le producteur veut abstraire pour simplifier tout le reste de la chaine de traitement).Niveau production, le JSON est tout aussi simple, un
json_encoded’une structure langage du standard (la même quejson_decode) et c’est plié.Par comparaison avec RSS/Atom, dans la plupart des langages dans la lib standard tu as au mieux une API type DOM pour faire du XML. Et lire/produire du RSS/Atom à partir d’une simple API type DOM, ce n’est certes pas la fin du monde, mais c’est infiniment plus compliqué et ce n’est certainement pas quelque chose que tu veux refaire n fois un dans un projet composé d’une multitude d’exécutables différents et indépendants et même écrits dans des langages différents.
tl;dr: haters gonna hate, mais aujourd’hui en 2014 JSON a gagné haut la main et c’est LE langage d’interopérabilité par excellence. On ne devrait plus justifier l’utilisation de JSON mais bien plutôt sa non-utilisation, et dans le cas de la non-utilisation la justification devrait être solide.