next_batch token in the last page

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.

Cour-de-cassation / judilibre-search

next_batch token in the last page #82