JSON Feed : le nouveau format de syndication pour diffuser les flux d'informations est disponible en version 1.0
Pourra-t-il détrôner RSS et Atom ?

Le , par Olivier Famien, Chroniqueur Actualités
Quel(s) format(s) de syndication préférez-vous pour diffuser vos flux d'informations ?
À la veille des années 2000, alors les outils sur internet étaient en pleine émergence, le format de données RSS utilisé pour diffuser les flux d’informations a vu le jour. Au fil des années, ce format a gagné en maturité afin d’atteindre en 2002 sa version 2.0, largement utilisée par les internautes pour délivrer en continu des flux d’informations sans que l’utilisateur ait besoin par exemple d’ouvrir son navigateur, se rendre sur une page, cliquer sur les liens afférents afin de lire l’information voulue.

En dépit des avantages apportés par le format de syndication RSS, certains lui trouvèrent de nombreux défauts techniques comme, l’impossibilité d’effectuer des changements directement sur la version 2.0. Cela a amené un groupe de personnes à réfléchir sur un format de syndication beaucoup plus riche en fonctionnalités et en 2003, les premières versions d’Atom ont vu le jour.

Tout comme RSS, ce format de syndication permet à une plateforme, un site, etc. de diffuser du contenu et à un internaute de suivre les informations provenant de ces plateformes, sites d’actualité, blogs, etc. en utilisant un agrégateur de fils d’actualités. En 2004, pour faire avancer les travaux, Atom fut confié à IETF (Internet Engineering Task Force), un groupe informel, international participant à l’élaboration des standards internet et en 2005, la première version stable d’Atom a vu le jour. Dans la même année 2005, le format de syndication Atom fut proposé comme un standard de protocole officiel pour internet.


En plus d’avoir les fonctionnalités de base de RSS, Atom est un format ouvert permettant l’usage d’une licence moins restrictive que RSS. Par ailleurs, il supporte l’espace de noms XML, l’identifiant uniforme de ressource (URI en anglais), un type MIME enregistré IANA et le langage de description Relax NG (Regular Language for XML Next Generation). Depuis des années, ces deux formats qui sont basés sur XML sont utilisés selon leur préférence par les sites d’actualités, blogs et autres sources d’informations afin de diffuser des informations auprès des utilisateurs.

Toutefois, à ces deux ténors, il va falloir rajouter un nouvel arrivant baptisé JSON Feed. JSON Feed est un nouveau format de syndication basé non pas sur XML, mais plutôt sur JSON. Il est l’œuvre de deux développeurs qui ont entamé ce projet en raison de la popularité du format de données JSON. Pour les personnes extérieures à l’environnement, JavaScript Object Notation abrégé JSON est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Il permet de représenter de l’information structurée comme on le ferait avec XML. Les développeurs déclarent qu’ils « ont remarqué que JSON est devenu le choix des développeurs pour les API, et que les développeurs s’arrangent souvent pour éviter le XML ». Ils ajoutent que « JSON est plus simple à lire et à écrire, et il est moins sujet aux bogues ». Aussi, ont-ils souhaité offrir à la communauté web une alternative aux deux formats de syndication RSS et Atom basés sur XML.

JSON Feed est disponible en version 1.0 et comporte les éléments suivants :

  • en haut, nous avons des informations comme la version, le titre, l’URL de la d’accueil, l’URL qui alimente le format de syndication, l’auteur du fil d’informations, des hubs qui se présentent comme des points d’entrée pour souscrire à des notifications envoyées en temps réel par un éditeur de flux, etc.  ;
  • à la suite, nous avons une collection d’objets, des items en l’occurrence, qui décrivent chaque objet dans la liste. Ce sont par exemple l’identifiant le format de syndication, l’URL de la ressource décrite par l’item, un titre en texte clair, un résumé décrivant l’item, l’auteur du fil d’informations, des tags, la date de modification, etc.  ;
  • des pièces jointes qui peuvent être attachées à un item. Ces pièces jointes comportent des propriétés comme l’URL où se trouve la pièce jointe, un type MIME qui spécifie le type de la pièce jointe, la taille du fichier en octets, la durée en seconde  ;
  • des extensions qui s’apparentent à des objets personnalisés utilisés par des diffuseurs de flux d’informations dans JSON Feed  ;
  • et bien d’autres fonctionnalités.


Il faut noter que JSON Feed est basé sur JSON, ce format de syndication comporte de nombreuses similitudes avec RSS et Atom. Et pour les prochaines versions, les développeurs promettent encore plus de fonctionnalités et précisent que les versions supérieures seront toujours compatibles avec les flux d’informations conçus avec les versions antérieures.

À en croire les fonctionnalités mises en avant par les développeurs de ce projet, JSON Feed a tous les atouts pour se faire une place dans la famille des formats de données utilisés pour la syndication du contenu web. Mais y a-t-il encore de la place à prendre quand on sait que les deux premiers formats (RSS et Atom) ont largement conquis le cœur des utilisateurs ?

Source : JSON Feed

Et vous ?

Que pensez-vous de ce nouveau format de syndication ?

Pourra-t-il se faire une place de choix auprès des ténors comme RSS et Atom ?

Voir aussi

Quelle solution utilisez-vous pour diffuser du flux RSS ? Partagez votre expérience.
Google Reader est mort, les utilisateurs ont jusqu’au 15 juillet pour déplacer les données

La Rubrique Développement Web, Forum Web, Cours et tutoriels Web, FAQ Web


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de psychadelic psychadelic - Membre chevronné https://www.developpez.com
le 26/05/2017 à 0:34
je préfère Jason Feed. ===> : JSON Feed
ou alors il s'agit de la toison d'or ?

Utiliser un format JSON plutôt que XML est 1 million de fois plus évident pour faire de l'internet.
Interpréter du XML en javascript est le meilleur moyen de se planter dans son code, surtout s'il s'agit d'un micro format comme RSS ou AtoM, qui ne sont pas toujours livrés très propres, et finissent immanquablement à planter les interpréteurs XML, quels que soient le langage utiliser.

Alors que le JSON est natif en javascript, et depuis nodeJS, il est déployable n'importe ou et à peu de frais. On ne peut pas en dire autant du XML.
JSON est aussi un format largement en bigDATA, et ce n'est pas uniquement pour des raison de volume (un fichier XML sera toujours "100 fois" plus gros qu'un fichier JSON pour des informations identiques).
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 26/05/2017 à 9:23
Ce format seras bien plus simple à mettre en place que RSS et ATOM quelque soit le langage du générateur tant qu'il gère les tableaux associatifs
Avatar de mothsART mothsART - Membre régulier https://www.developpez.com
le 27/05/2017 à 15:29
Les développeurs déclarent qu’ils « ont remarqué que JSON est devenu le choix des développeurs pour les API, et que les développeurs s’arrangent souvent pour éviter le XML ». Ils ajoutent que « JSON est plus simple à lire et à écrire, et il est moins sujet aux bogues ».
Je suis pas foncièrement un défenseur du XML mais ce genre de déclaration est à mon sens trollesque.
* On ne choisi pas une techno parce qu'elle est plus populaire à mon sens.
* les développeur n'évitent pas forcément XML à mon sens : c'est encore très utilisés.
* JSON est moins sujet aux bugs : ah bon ?? Pas de namespaces, typage quasi inexistant, pas de format de validation officiel (DTD ou XSL Shema officiel pour le XML)
* les libs pour le XML (ainsi que RSS et Atom) sont éprouvés : si tu utilises un truc fait main pour intépréter du xml, forcément c'est sujet à plantage => ça sera pas forcément mieux pour Json Feed.
* plus simple à lire ou écrire : au format brut sans doute mais avec des IDE, la différence est inexistante
* Si c'est une question de taille, MessagePack est encore meilleur que Json.

Mon opinion sur Json : https://mothsart.github.io/ce-nest-q...voir-json.html
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 27/05/2017 à 18:40
Citation Envoyé par mothsART Voir le message
* On ne choisi pas une techno parce qu'elle est plus populaire à mon sens.
le client est roi,on à pas toujours le choix
Citation Envoyé par mothsART Voir le message
* les développeur n'évitent pas forcément XML à mon sens : c'est encore très utilisés.
la news ne mentionne pas pas cela mais dit qu'ils "privilégient" le JSON
Citation Envoyé par mothsART Voir le message
* JSON est moins sujet aux bugs : ah bon ?? Pas de namespaces, typage quasi inexistant, pas de format de validation officiel (DTD ou XSL Shema officiel pour le XML)
//normes(en cours de validation depuis 2013(plusieurs réécritures pour désacords), l'IETF est longue et pointilleuse)
http://json-schema.org/documentation.html
https://tools.ietf.org/html/draft-wright-json-schema-00
http://json-schema.org/latest/json-s...ypermedia.html
//validateurs bien utilisés et reconnus
https://sourceforge.net/projects/jsonschemaphpv/
http://www.jsonschemavalidator.net/
http://www.newtonsoft.com/jsonschema
Citation Envoyé par mothsART Voir le message
* Si c'est une question de taille, MessagePack est encore meilleur que Json.
c'est un système de conversion/déconversion en binaire du JSON NORMAL, cela n'à rien à voir
Citation Envoyé par mothsART Voir le message
On ne ta pas demandé si tu aimait on non Javascript et par extension de déverser ta haine sur le JSON
Avatar de mothsART mothsART - Membre régulier https://www.developpez.com
le 28/05/2017 à 14:00
Bon TiranusKBX, tu précises bien que les normes sont en cours de validation.
Pour moi : Pas de norme = pas de lib qui implémente la norme (ou lib potentiellement obsolète) = pas de format de validation

Tu cites NewtonSoft donc le support sur C sharp : le soucis c'est que d'autres langages n'ont pas un support aussi poussé.
Et l'on ne peut pas anticiper dans quels langages vont être dev les clients.

C'est pas un problème en soit mais dire que XML (qui a déjà des libs matures dans pleins de langages pour de la validation) est moins sécure que JSON n'est à mon sens et pour l'ensemble de ses raisons pas honnête. (aujourd'hui : il le sera peut-être demain)

Dire que Json est plus sécure dans le cadre de Javascript, je ne nierais pas l'évidence mais ça n'est pas suffisant. (le web ne se limite pas à ce langage)

c'est un système de conversion/déconversion en binaire du JSON NORMAL, cela n'à rien à voir
Je ne sais pas d'ou tu tiens cette ineptie mais c'est un format de sérialisation en binaire. (leur slogan étant : it's like JSON but fast and small => cqfd)
Il y pas mal de comparatif sur leur site avec Json mais ça s'arrête là.
De toute façon, ce qui transite c'est bien le format de messPack et non du Json => il y a donc bien une différence de taille quantifiable.

On ne ta pas demandé si tu aimait on non Javascript et par extension de déverser ta haine sur le JSON
Je ne crois pas avoir parlé de javascript...

Pour ce qui est de Json, la news parle bien de passer du Xml au Json et je ne fais pas parti de ceux qui vont encenser ce format à tout va.
On choisit à mon sens une techno pour ce qu'elle fait de mieux et non une techno pour à peu près tout du moment qu'elle est populaire.

Après, désolé de poser les questions qui fâches mais si l'on diffuse un nouveau format, pour ma part, il faut que ça en vaille le coup ?? Et là clairement, ça me parait maigre.
Avatar de secou secou - Nouveau Candidat au Club https://www.developpez.com
le 29/05/2017 à 11:53
Merci pour l'article. Quelques précisions néanmoins.

RSS vs Atom
Il ne me semble pas qu'Atom soit beaucoup plus puissant que RSS en terme de format de publication. Un peu moins facilement "lisible" dans sa structure, il a néanmoins ajouté quelques petits plus par rapport au format RSS, notamment la possibilité d'associer plusieurs auteurs à un même article (<contributor>), la possibilité d'ajouter une métadonnée sur les droits d'usage du fil et des articles (<rights>), un "résumé" pour chaque article (<summary>, rarissimement utilisé...
Contrairement à ce que l'article laisse entendre, RSS prévoit tout à fait la possibilité de lui associer des espaces de nom (extensions), comme celui d'iTunes pour les podcasts, par exemple.
Ce qui fait la force d'Atom, c'est notamment qu'il a été conçu avec un format de publication (The Atom Publishing Protocol).
Mais reconnaissons qu'Atom est faiblement utilisé en tout cas en ce qui concerne des fils "visibles" par les utilisateurs. Seules grosses exceptions : Google Alertes et Blogger.
Le problème reconnu de ces deux formats, c'est qu'il n'imposent pas la saisie d'un identifiant unique (GUID) pour chaque article. Et comme se sont deux formats assez ouverts, contenant chacun quelques ambiguïtés tenaces sur leur mise en forme (malgré la rédaction d'un "RSS Profile" par le RSS Advisory Board... rarement respecté), nombre d'entre eux sont mal formés et posent donc sans doute plein de problèmes à qui veut les convertir en JSON.

JSON Feed
JSON Feed, en termes de balises associées, est très (très) proches de RSS et Atom... mais impose un GUID. Je comprends (je ne suis pas développeur) qu'il serait beaucoup plus facile à gérer notamment pour des développeurs d'applis mobiles et d'API.
Le problème, c'est sa capacité à être largement adopté du côté des producteurs de contenus... et ça c'est loin d'être gagné. Pour un blogueur ou une entreprise, il n'y pas d'intérêt particulier à ajouter des fils au format JSON Feed à son site (en dehors d'être "tendance").
Du côté des lecteurs de fils RSS, les plus réactifs, NewsBlur, Feedbin et Inoreader l'acceptent déjà... quid des autres ?
JSON Feed prendra son envol si une grosse plateforme en génère par défaut (au hasard WordPress, ce qui n'est pas gagné) ou si Google (avec sa force redoutable de normalisation du Web [voir l'AMP]) le recommande pour améliorer son référencement.
Il décollera dans le "grand public" si un écosystème se créé, ce qui n'est toujours pas le cas pour RSS et Atom : des extensions d'abonnement pour tous les navigateurs permettant aux "veilleurs" de facilement les rediriger vers leur lecteur de fils pour s'y abonner, des extensions pour les CMS majeurs (WordPress, c'est fait), etc.
Avatar de psychadelic psychadelic - Membre chevronné https://www.developpez.com
le 07/06/2017 à 2:04
Citation Envoyé par mothsART Voir le message
* JSON est moins sujet aux bugs : ah bon ?? Pas de namespaces, typage quasi inexistant, pas de format de validation officiel (DTD ou XSL Shema officiel pour le XML)
C'est toute la différence entre JSON et XML : pas besoin de DTD ou de XML schema, pas besoin d'outils couteux comme XML Spy, etc...
JSON est uniquement pensé pour rester simple.
une accolade ovrante doit trouver une accolade fermante, idem pour les crochets et les doubles-quotes.
L'écriture d'un parseur JSON est ultra simple,
Après que les données soient vraiment propres et cohérentes, c'est un autre problème mais au moins on ne risque pas de tout planter comme en XML avec un balisage corrompu.
JSON n'a pas les prétentions du langage XML, il ne demande pas d'outils sohistiqués pour faire le jobs
On n'a pas besoin d'une armada de code pour présenter un flux RSS sur une page Web, faut pas déconner.

Bien XML à fait pas mal fantasmer à une époque, mais en tant que codeur, toutes ses montagnes de librairies pour juste transférer des données, même en pouvant faire de l'analyse de flux et autres "plaisirs" ça me semble aujourd'hui complètement délirant.
En JSON on détecte très vite les erreurs de cohérence dans le balisage, sans avoir à se battre contre des balises et des tags et autres subtilités pour des besoins finalement plutôt simples.
Aller j'ose l'écrire : le XML c'est de la masturbation intellectuelle, na
Offres d'emploi IT
Responsable de projet (calculateur moteur) H/F
Safran - Ile de France - Massy (91300)
Responsable de lot / architecte fpga H/F
Safran - Ile de France - Éragny (95610)
Architecte / concepteur électronique numérique H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil