Exposer une API à-la-FreshRSS

[thom4parisot]

Visiblement FreshRSS a l'air populaire.

Pour m'affranchir temporairement de la limite 3 jours des News+Collections, j'allais importer un OPML dans NetNewsWire. Et je vois que le logiciel propose de se brancher à son compte FreshRSS.

Du coup, je propose l'idée d'avoir au moins en lecture les API HTTP nécessaires pour importer/synchroniser son compte dans d'autres outils, comme si Flus était du FreshRSS (parce que, pour l'intégration dans l'écosystème des logiciels RSS existants).

[marienfressinaud]

Je suis un peu embêté parce que créer et maintenir une API représente quand même beaucoup plus de taf que répondre à ta demande initiale. Du coup, je ne sais pas si tu as un besoin plus profond qui viendrait sous-tendre ta demande.

D'autres raisons qui font que je suis frileux :

1. si d'autres applis s'y branchent, l'utilisateur perdra l'expérience propre à Flus. Je me pose donc la question de pourquoi l'utiliser à la place d'un autre agrégateur ?
2. il y a deux API dispo au sein de FreshRSS, est-ce que cela veut dire que je dois gérer également les deux pour être cohérent ?
3. dans l'idéal, je préfèrerais qu'on n'ait pas à choisir l'option FreshRSS pour sélectionner Flus pour la clarté (mais on est d'accord que le coût d'ajout de Flus aux applis serait beaucoup moins élevé à partir du moment où les API sont les mêmes)

Bref, c'est pas un refus catégorique, mais pour l'instant je ne vois pas l'intérêt de bosser dessus et ne vois pas comment l'intégrer à mon flot de travail actuel.

[bnjbvr]

Salut, je viens juste rajouter un petit +1, et pour apporter un peu plus que ça 😊 :

si d'autres applis s'y branchent, l'utilisateur perdra l'expérience propre à Flus. Je me pose donc la question de pourquoi l'utiliser à la place d'un autre agrégateur ?

Je pense que l'enjeu de l'interopérabilité, c'est proposer des usages auxquels tu n'a pas pensé, ou un point de vue différent sur les mêmes données, etc. Ce qui est un gros avantage du libre sur le monde propriétaire, qui essaie de cantonner les utilisateur.ice.s dans l'utillisation de leur suite logicielle. Ici c'est l'effet inverse qu'on cherche.

Après, j'entends que c'est beaucoup de travail. Quel sous-ensemble d'une solution suffirait à satisfaire la plupart des besoins ? Je sais que plusieurs clients RSS implémentent un support pour l'API Fever (supporté par le serveur de FreshRSS, notamment) ; est-ce assez petit pour être suffisant ?

Lien vers la page de doc de Freshrss sur Fever

[marienfressinaud]

Oui tu as raison @bnjbvr ! Ça fait quelques temps que ça me trotte dans la tête cette demande d’API qui revient à intervalle régulier. Il y a toutefois deux formes d’API qui peuvent être envisagées :

La première, qui répond à ta demande, c’est d’avoir une API prévue pour fonctionner avec des agrégateurs (mobiles ou non) "standards". Si on ne cherche à répondre qu’à ce besoin, répliquer une API existante style Fever est une option suffisante qui, même si ça demande un peu de taff, n’est pas non plus si compliqué que ça (le code dans FRSS tient en moins de 600 lignes https://github.com/FreshRSS/FreshRSS/blob/edge/p/api/fever.php).

La seconde, c’est une API qui permette de tirer pleinement profit des fonctionnalités de flusio, dont la gestion des collections par exemple. On parle donc d’une API sur-mesure. On peut envisager de l’implémenter de deux façons différentes :

1. en étendant les endpoints d'une API-existante-style-Fever
2. en implémentant une API absolument propre à flusio

Paradoxalement, ce serait cette dernière solution qui me semble demander le moins de boulot. Le routage actuel forme déjà une base qui me semble solide, il resterait à ajouter des entrées et sorties JSON. Ça me semble assez facilement généralisable concernant les entrées, peut-être plus long pour les sorties. D’un point de vue "esthétique applicative", c’est cette solution que je préfère. Bon, c’est aussi cette dernière solution qui répondra le moins à vos demandes à tous les deux 😅

Dans tous les cas il faudra envisager un système d’autorisations par token, mais ça ne me semble pas particulièrement compliqué puisque j’ai déjà une table pour stocker des tokens (resterait à créer l’interface quoi).

Voilà où j’en suis de mes réflexions concernant ce point spécifique de l’API, sachant que je suis également en plein flou artistique concernant l’ambition et ce que je veux faire avec Flus, y compris des trucs très structurant comme le journal :D