JSON Feed : un successeur pour le RSS

Manton Reece et Brent Simmons en avaient assez de voir certains développeurs Web pester contre le RSS et son formatage XML. Pire, ils avaient peur que la disparition des flux RSS s’accélère à cause de ce problème. Au lieu de pleurer sur Twitter, ils ont fait un truc rare de nos jours : ils ont agi et mis au point une solution, JSON Feed.

JSON Feed Icon

Et même l’icône est mimi.

JSON Feed, c’est une nouvelle façon de publier et syndiquer son contenu sur le Web. À l’instar du RSS, ça permet de le diffuser largement et de le rendre lisible sur des applications tierces, comme l’excellent Inoreader dont j’ai largement parlé dernièrement. Mais c’est Newsblur qui est le premier à gérer ce nouveau format.

Qu’est-ce que ça change pour vous ? Rien. Ou presque : ce nouveau format est beaucoup plus simple à mettre en place pour les devs Web et devrait éviter les feeds RSS en carton qu’on peut trouver sur plein de sites. On peut rêver à un meilleur parsing, avec des flux plus lisibles. Évidemment, ça ne changera pas les mentalités de certains qui refusent ce genre de système par peur de perdre de l’affichage côté pubs. L’existence de cette option JSON offre un choix supplémentaire aux développeurs et je pense que la plupart des lecteurs de RSS / Atom vont l’intégrer assez rapidement. JSON Feed c’est bon pour l’open web, c’est bon pour la lecture, mangez-en !

Les liens utiles :

Vous devriez également aimer…

Commentaires
  1. Tu veux dire que @MisterP va devoir renoncer à une de des nuits de débauche ? :smiley:

  2. Tout pareil que les 2 monsieurs au dessus. RSS c'est pas parfait, mais json c'est pas non plus revolutionnaire.

    Ca me rappelle beaucoup ca :

  3. Aucun risque pour ma part, c'est juste que je cherche à comprendre (voire à être convaincu).

    En cherchant un peu plus :
    - La simplicité du format permet une meilleure lecture à l'œil nu / débogage
    - Il y a pléthore de fonctions pour transformer tout type de structure de données en json (et inversement)
    - Rendre l'Id obligatoire, je ne savais même pas qu'il ne l'était pas dans les specs rss/xml ^^; Donc là c'est clairement un gros plus oui
    - Et surtout : les specs lèvent également quelques limitations du rss/xml, genre plusieurs "attachments" au lieu d'un seul, et un typage(ce n'est pas le bon mot, mais je ne trouve pas mieux) de certains objets comme les icones, favicon, images pour éviter de passer par des astuces pour contourner la limitation rss/xml, mieux adapter aux pratiques modernes

    Donc effectivement, j'ai été trop vite dans ma réponse, my bad.

  4. Les critiques qui pointent du doigt les problemes avec une nouvelle spec n'ont pas tord:

    • Ca fait une spec en plus
    • Ca fait genre "les hipsters ils aiment pas l'XML parce que c'est vieux, et comme c'est vieux c'est nul", ce qui est une facon de penser assez commune et regrettable chez les devs web de nos jours (il suffit de voir l'evolution des frameworks JS, c'est a la fois hilarant et triste)
    • etc.

    Mais pour moi ces critiquent passent a cote du point le plus important, la facilite a developper, et de ses (potentielles) consequences.

    D'abord, c'est bien joli de dire que tous les languages ont des bons parseurs XML. Oui, c'est vrai, mais il faut voir ce que ca vous crache derriere. Premierement, ca vous donne un arbre d'objets a naviguer avec des nodes, de attributs, etc. Y'a les namespaces qui foutent le boxon dans toutes vos queries parce que ca change le nom des nodes... ah, vos extensions pour Atom ou RSS qui permettent de mettre des attachements ou des infos supplementaires ne marchent pas? Est-ce que vous avez la bonne URI pour les namespaces d'extensions? Est-ce que vos requetes XPath sont foirees? Et j'en passe... serieux, 80% des errors de flux sont a cause d'XML malforme.

    En comparaison, le JSON dans tous les frameworks, c'est un appel de fonction et vous recuperez un dictionnaire. Y'a un seul moyen de le consommer, parce que c'est rien de plus que ca. Apres oui le manque de schema ne va surement pas empecher de generer des JSONFeeds malformes non plus, mais les questions a se poser se resumeront plus ou moins seulement a "est-ce que c'est le bon nom de clef?".

    C'est pas un hasard que les devs de lecteurs RSS implementent tous le support pour JSONFeed aussi rapidement: d'abord, c'est tellement facile que ca leur coute rien. Mais aussi, c'est parce qu'ils esperent tous pouvoir passer leurs journees a faire autre chose que d'ecrire des hacks pour gerer du XML moisi.

    Mais c'est la qu'on arrive a l'idee interessante de JSONFeed. Vous savez pourquoi les 99% des tutorials de dev sont: une TODO list, un blog, ou un client Twitter? C'est parce que c'est facile a faire, et que ca semble vaguement utile. Maintenant, que va-t-il se passer si un quart de ses tutorials devenaient un client JSONFeed basique? Ca pourrait potentiellement remettre ce genre de truc dans l'esprit de la prochaine generation de codeurs et, du coup, faire lentement remonter le nombre de gens qui s'y interessent.

    Est-ce que ca va marcher? J'en sais rien mais franchement on s'en fout vu que, justement, ca prend meme pas 5 minutes de rajouter un JSONFeed sur son site, et, apparemment, pas bien plus pour le rajouter dans une app de lecture de flux. Grosso-modo, ca prend plus de temps de raler dessus que de le faire et de croiser les doigts.

    Apres, si vous avez d'autres idees pour stopper la centralisation rampante du web, je suis preneur aussi, hein.

  5. Dans mes bras...

    Dans le genre "le saviez-vous" le RSS dit que dans la balise "author" il faut mettre un mail
    https://validator.w3.org/feed/docs/rss2.html#ltauthorgtSubelementOfLtitemgt
    et que le nom de l'auteur doit être dans "dc:creator" mais il faut le namespace adéquat parceque c'était pas prévu à la base
    http://www.rssboard.org/rss-profile#namespace-elements-dublin-creator

    Sauf que tu te retrouves avec des RSS où les mecs mettent juste un nom dans "author" sans mettre de "dc:creator"
    Tu as ceux qui le mettent au bon endroit mais ne déclarent pas le namespace (GZ via Feedburner par exemple)
    Et puis ceux qui ne mettent pas d'auteur du tout.

    C'est juste un exemple tout con hein. Des cas particuliers comme ca tu en presque partout dans un rss. Bref, c'est le bordel et les parsers que tu trouves (magpie, simplepie, etc...) ont tous des manières différentes de gérer ça.

    Avoir une alternative qui essaye de normer ce bordel qui s'est construit au fil des ans avec pleins d'ajouts successifs c'est pas plus mal.

    /my 2 cents de pas dev

18 autre(s) commentaires