Sujet : pagination
-
Pagination de l'API Stripe et clés d'idempotence : starting_after, has_more et la fenêtre de 24 heures
Les endpoints de liste v1 de Stripe paginent avec les paramètres de curseur mutuellement exclusifs starting_after/ending_before (limit de 1 à 100, 10 par défaut) et un indicateur has_more, des assistants de pagination automatique des bibliothèques clientes permettant de parcourir toutes les pages. Les requêtes POST peuvent porter un en-tête Idempotency-Key dont Stripe rejoue le résultat enregistré pendant environ 24 heures, après quoi les clés peuvent être supprimées. Les requêtes limitées reçoivent un 429 avec un en-tête Stripe-Rate-Limited-Reason.
-
Tester les curseurs de continuation après un changement d'identité de la requête
Vérifier la politique de visibilité de l'application quand un curseur de continuation est réutilisé sous un principal différent. Cette méthode originale traite le curseur comme faisant partie d'un contexte de requête dont la signification en matière de sécurité doit être spécifiée.
-
Prouver la portée d'un inventaire paginé avant d'effectuer des changements en masse
Établir exactement quels objets une lecture paginée a couverts avant de l'utiliser comme entrée d'une modification en masse, d'une proposition de suppression ou d'un plan de migration.
-
Suivre @odata.nextLink dans Microsoft Graph et gérer la limitation 429 et les limites du traitement par lots
Microsoft Graph pagine les grandes collections via une URL @odata.nextLink, à suivre telle quelle comme un jeton opaque sans l'analyser ni la reconstruire. Il accepte des tailles de page définies par le client avec $top, limite le débit par un HTTP 429 accompagné d'un en-tête Retry-After, et plafonne une requête batch JSON à 20 sous-requêtes.
-
Pagination et erreurs de quota des API Google : pageToken, 403 rateLimitExceeded et 429
Les API Google Workspace comme Calendar et Drive paginent avec le couple pageToken/nextPageToken et maxResults (Calendar) ou pageSize (Drive). Drive signale une surcharge de deux façons, par un HTTP 403 (reason rateLimitExceeded ou userRateLimitExceeded) ou par un HTTP 429 (reason rateLimitExceeded). Dans les deux cas, la documentation prévoit de réessayer avec un backoff exponentiel, contrairement aux autres motifs de 403.
-
Paginer l'API REST de GitHub et lire les en-têtes des limites de débit primaires et secondaires
L'API REST de GitHub pagine via un en-tête link contenant des URL rel="next"/"last" et un paramètre per_page plafonné à 100 pour la plupart des points de terminaison. Les limites primaires sont indiquées dans x-ratelimit-limit/remaining/used/reset/resource, les limites primaires comme secondaires répondent par 403 ou 429 (parfois avec retry-after pour les secondaires), et un GET conditionnel autorisé qui renvoie 304 ne compte pas dans la limite primaire.
-
Détecter les pages dupliquées dans les flux paginés par curseur
Arrêter les boucles de pagination grâce à la détection des curseurs répétés, tout en dédupliquant les enregistrements par identité stable et révision.
-
Paginer l'API Web de Slack et gérer les paliers de limitation de débit par méthode
L'API Web de Slack pagine par curseur via response_metadata.next_cursor et un paramètre limit (100 à 200 recommandé, maximum 1000, susceptible de changer et variable selon la méthode). Elle applique des paliers de limitation par méthode et par espace de travail, de 1+ à 100+ requêtes par minute, et renvoie un HTTP 429 avec un en-tête Retry-After en secondes en cas de dépassement.
Lisible par machine : JSON