next_batch token in the last page

[anteverse]

Bonjour,

La stratégie actuelle permet d'obtenir 10k résultats pour une query donnée. Et le franchissement de cette limite retourne un statut 416.
Lorsqu'on requête l'avant-dernier batch, le champ next_batch dans la réponse devient null, ce qui a du sens car la prochaine requête donnera un statut 416.

Serait possible de continuer à fournir un next_batch pour lequel la query a changé, et plus particulièrement les filtres sur les dates lors d'un appel à /export par exemple.

Un exemple :

• dernière requête pour une query donnée : https://api.piste.gouv.fr/cassation/judilibre/v1.0/export?resolve_references=true&date_end=3000-01-01&batch_size=100&date_type=creation&batch=99&order=desc
  • la valeur de next_batch est nulle ici
  • il y a encore des décisions qui correspondent à cette recherche, sur les prochaines pages, et d'après les dates des décisions listées on pourrait reconstruire un next_batch. Il pourrait devenir par exemple : resolve_references=true&date_end=2021-05-06&batch_size=100&date_type=creation&batch=1&order=desc

Plusieurs notes à ce sujet :

• j'imagine que la limite de 10k résultats n'est pas un rate-limiter mais plutôt une façon de limiter la complexité de la pagination sur la base source ? De plus on a déjà un rate-limit sur le compte Piste.
• ce changement de query est possible par le client déjà, peut-être qu'il pourrait être géré côté serveur plutôt ?
• lors du switch de query, il y a potentiellement un overlap sur les dates, ce pourrait être géré avec des timestamps.

À l'inverse, si c'est vraiment une mesure de rate-limit, à l'heure actuelle rien n'empêche le client de switcher tout seul et donc le rate-limit est contourné et ce n'est pas le comportement voulu.

S'il y a une meilleure stratégie à adopter côté client, n'hésitez pas à me le signaler. Disponible pour contribuer et tester.

[SebCourvoisier]

Bonjour,
Problème analogue à #88 (limitation intrinsèque), contournement en cours d'étude.