Je suis toujours dans mes sauvegardes. Je veux avoir une copie de tout dans mes sauvegarde, données des services en ligne incluses.
Je pensais faire ça facilement avec Pocket. Ils ont une API, assez simple.
En pratique je me retrouve à faire essentiellement de l’ingénierie inverse. La documentation indique des choses qui n’existent pas ou ne fonctionnent pas, et ne donne aucune information sur des éléments essentiels qu’on reçoit (genre la gestion des erreurs).
Authentification
Contrairement aux mécanismes OAuth habituels, leur authorize ne renvoie pas de code temporaire à échanger. Pour récupérer l’access_token, il faut le demander avec le request_token obtenu lors de l’échange serveur à serveur initial.
Ce request_token semble ne pas avoir de durée de vie. Il n’a en tout cas pas de refresh_token associé.
Mécanisme de régulation
L’API indique des limitations à 320 appels par heure. C’est d’autant plus important que pour télécharger mes plus de 29 0001 items par pages de 30 maximum, je vais forcément dépasser le nombre de requêtes que je peux faire en une heure.
Il y a un mécanisme automatique prévu pour la régulation mais le serveur n’envoie pas les entêtes prévues pour ça. Je sais juste qu’au bout d’un moment j’obtiens des erreurs 403 et que ça semble venir de là.
Je vais devoir gérer ça à la main. Pour l’instant je note l’heure de chaque requête dans un tableau. Quand mon tableau fait 320 éléments, je retire le premier élément et attend l’heure de cet élément + 1 heure avant de continuer.
Pagination
Le mécanisme pour la pagination est assez famélique : 30 items maximum par requête, plus un offset pour passer à la page suivante. C’est une mauvaise méthode pour itérer à travers des milliers d’items et ça ne trompe pas : Les requêtes sont effectivement de plus en plus lentes au fur et à mesure des pages. C’est visible et c’est pénible.
Le serveur prévoit de renvoyer un champ total qui permet de savoir s’il reste encore des éléments. Les réponses du serveur ne me renvoient malheureusement pas ce champ alors je vais juste itérer jusqu’à obtenir une réponse vide sans erreur.
Il y a aussi un champ since qui permet de limiter la recherche aux éléments plus récents qu’une certaine date. J’imaginais pouvoir me baser là dessus pour la pagination : Parcourir du plus vieux au plus récent, identifier la date du plus récent et repartir de là à la prochaine itération. C’est d’ailleurs la procédure recommandée pour beaucoup de services qui veulent éviter les problèmes que pose le parcours par offset. Malheureusement ça n’est pas utilisable pour la pagination : les items retournés ne sont correctement ordonnés ni par date d’ajout ni par date de modification.
Étrangement, il semble que la limite de 30 items par page ne soit pas forcée. Il semble que ça fonctionne avec beaucoup plus, mais que ça génère aussi plus d’erreurs. Le meilleur compromis semble effectivement dans les 25 à 30 items par page.
Dernière spécificité, j’ai l’impression de temps de réponse plus longs et d’erreurs plus fréquentes quand je vais du plus vieux au plus récent. Je n’ai pas vérifié cette impression avec des chiffres mais autant rester sur l’ordre par défaut : du plus récent au plus vieux.
Documentation incomplète
J’ai dit qu’il me manquait les entêtes de régulation et le champ total à la racine de la réponse. À l’opposé, j’ai quelques champs qui ne sont pas dans la documentation.
Le status semble être un entier avec, 0 pour une erreur, 1 pour OK, 2 quand il n’y a rien à afficher depuis une mise à jour. Quand status est à 0, le champ error contient le message d’erreur.
Il y a aussi un maxActions, dont je ne connais pas le sens.
Données irrécupérables sur le serveur
Pour une raison ou une autre, certaines de mes données semblent corrompues ou irrécupérables sur leur serveur (comme quoi la sauvegarde est utile ;-)..
J’ai 20 items qui provoquent systématiquement une erreur 504. Je peux récupérer ceux avant, ceux après, mais pas ceux là2. C’est vrai peu importe le sens de parcours (mais les offset ne sont logiquement pas les mêmes dans les deux sens).
Je n’ai pas plus d’explication. Je ne peux même pas connaitre les identifiants concernés pour demander leur suppression.
Potentiellement ce sont des données qui ne peuvent plus être réhydratées sur leurs serveurs, soient qu’il manque des informations essentielles, soit que leurs composants ne savent pas compléter ce qui manque (le serveur du lien sauvegardé qui répond bizarrement ?).
Erreurs aléatoires
Même avec une pagination basique, dans l’ordre par défaut, j’ai des erreurs fréquentes, aléatoires.
La plupart des 403 semblent liées à la limitation du nombre de requêtes, mais pas forcément toutes.
La plupart des 504 semblent liées à mes données irrécupérables mais il est arrivé que ça finisse pas passer quand même.
Les 502, en général il suffit de relancer la même requête, mais parfois l’erreur semble persister un moment.
Automatisation
Je parcours finalement tout par page de 30 et je mets à jour à chaque page le fichier de sauvegarde (pour les données récupérées) et le fichier de configuration (pour le nouvel offset de la prochaine requête). Si j’ai des erreurs inattendues, je pourrai relancer de là où j’en étais.
Si j’ai une page en erreur, je reprends tous les items de la page mais en allant les chercher mais 1 par 1 à partir de leur offset respectif. Parfois je ne retrouve pas l’erreur et ça permet de récupérer tout. Parfois l’erreur persiste sur un des éléments. Dans ce dernier cas l’idée c’est de pouvoir récupérer tous les bons items de la page et d’ignorer l’unique qui est en erreur.
Ça n’est pas parfait — si j’ai une erreur répétée mais temporaire sur un item, il sera ignoré silencieusement dans la sauvegarde — mais je n’ai pas mieux.
Une fois le parcours totalement fait une fois, je peux utiliser le since pour faire du différentiel.
Le code est sur https://github.com/edas/pocket-backup
RGPD à la rescousse
J’ai quand même prévu de faire une requête RGPD pour demander un export de mes données. On verra s’ils arrivent à me récupérer les 20 items qui sont en erreur permanente.
Si oui, je tenterai de les effacer pour reprendre un fonctionnement sans erreur. Sinon, je tenterai peut-être de réinitialiser le compte ou migrer ailleurs.
- Oui, tout ça. J’en suis moi-même étonné. J’ai tracé des usages depuis au moins fin 2010 mais je me demande si je ne l’utilisais pas au début de mon passage à Yahoo! en 2007–2008 du temps où ça s’appelait Read It Later. Ça fait une moyenne de 4 à 6 items par jour suivant la date retenue. ↩︎
- Je me les note pour moi-même : aujourd’hui ce sont les offset 14053, 14481, 17689, 18291, 18629, 19389, 20363, 20815, 20996, 20999, 21512, 21923, 22275, 22283, 22346, 23386, 23841, 24189, 24414, 27441. ↩︎