API Prélèvements - retourne code 400 sur dépassement page * size

[tgrandje]

Bonjour

J'utilise une boucle pour récupérer des résultats sur l'API en utilisant les champs "next" retournés par l'API. Lorsque le total des résultats dépasse 20k ouvrages, l'API fonctionne sur les premiers résultats, puis retourne un code 400.

Sur la forme : le message est relativement explicite (encore qu'en anglais): InvalidRequestInvalid stations requestValidatePageDepthplease refine your query. The multiplication ofpage*sizeparameters can not be more than 20000page

Il mériterait sans doute d'être :

• documenté avec un code d'erreur spécifique ;
• ("francisé" compte-tenu du périmètre de l'API ?)

Si le nombre de résultats plafonnés est par ailleurs limité, il conviendrait sans doute de retourner le code d'erreur dès la première pagination (le total étant calculé dès la première étape, inutile de se lancer dans une boucle interrompue à 20k enregistrements).

Exemple de requête fonctionnant/bloquées :

• https://hubeau.eaufrance.fr/api/v1/prelevements/referentiel/ouvrages?codes_departements=59,62&page=4&size=5000
• https://hubeau.eaufrance.fr/api/v1/prelevements/referentiel/ouvrages?codes_departements=59,62&page=5&size=5000

Sur le fond :

Je pencherais pour augmenter les volumes de données autorisés par l'API sur les ouvrages.

En effet, il est indiqué que le référentiel des communes/départements utilisé est celui de la BNPE, sans explicitations sur le millésime (ce que je conçois tout à fait compte-tenu du contexte). Il est donc délicat d'attaquer l'API avec une liste de codes communes (au risque de rater un ouvrage référencé sur un code commune obsolète), et la solution d'attaquer la base par code département est (à mon avis) la référence.

[tgrandje]

Nota : contournement possible en requêtant sur les codes communes (réels ou fictifs de 59001 à 59999, etc.).

[Supp-Hubeau]

Bonjour,

Une analyse du count présent sur la première page retournée permettrait de détecter que la requête ne sera pas intégralement servie si cette valeur dépasse la limite de 20000 mentionnée dans la section Limitations de la documentation de l'API.

Cordialement.

[tgrandje]

Bonjour @Supp-Hubeau

Effectivement, on peut bien sûr utiliser le count de cette manière, encore faut-il l'avoir aperçu dans l'onglet limitations (qui se trouve replié par défaut). Pour autant, je trouve le système actuel pas des plus explicites (dans la globalité) :

• le swagger indique qu'un code 400 est une requête incorrecte, alors que la requête est celle générée par l'API elle-même via le champ next ;
• par ailleurs, si peu qu'on ait raté l'explication sur la limitation, on a déjà généré/téléchargé environ 20Mo de fichiers avant de rencontrer l'erreur : sur le plan environnemental, on doit pouvoir faire mieux.

Je persiste à penser qu'un code d'erreur spécifique devrait être retourné dès la première requête dépassant les 20k. Ce n'est bien sûr pas indispensable, mais me semble relever des "bonnes pratiques" (surtout eu égard aux problèmes de codes communes qui amènent facilement à gonfler le niveau de données demandées à l'API, cf. supra).

Bonne journée