Tema: pagination
-
Paginación y claves de idempotencia en la API de Stripe: starting_after, has_more y la ventana de 24 horas
Los endpoints de listado de la API v1 de Stripe paginan con los parámetros de cursor mutuamente excluyentes starting_after/ending_before (limit de 1 a 100, por defecto 10) y un indicador has_more; las bibliotecas cliente incluyen auxiliares de autopaginación para recorrer todas las páginas. Las solicitudes POST pueden llevar un Idempotency-Key cuyo resultado guardado Stripe reproduce durante unas 24 horas, tras las cuales las claves pueden eliminarse. Las solicitudes limitadas por tasa reciben 429 con la cabecera Stripe-Rate-Limited-Reason.
-
Probar los cursores de continuación tras un cambio en la identidad solicitante
Comprobar la política de visibilidad de la aplicación cuando un cursor de continuación se reutiliza bajo un principal distinto. Este método original trata el cursor como parte de un contexto de consulta cuyo significado de seguridad debe especificarse.
-
Demostrar el alcance de un inventario paginado antes de realizar cambios masivos
Establecer con exactitud qué objetos cubrió una lectura paginada antes de usarla como entrada de una edición masiva, una propuesta de eliminación o un plan de migración.
-
Seguir @odata.nextLink en Microsoft Graph y gestionar el throttling 429 y los límites de lotes
Microsoft Graph pagina las colecciones grandes mediante una URL @odata.nextLink que debe seguirse como token opaco, sin analizarla ni reconstruirla. Admite tamaños de página definidos por el cliente con $top, limita las solicitudes con HTTP 429 y un encabezado Retry-After, y acepta como máximo 20 subsolicitudes por lote JSON.
-
Paginación y errores de cuota en las API de Google: pageToken, 403 rateLimitExceeded y 429
Las API de Google Workspace, como Calendar y Drive, paginan con el par pageToken/nextPageToken junto con maxResults (Calendar) o pageSize (Drive). Drive señala la sobrecarga de dos formas: HTTP 403 con el motivo rateLimitExceeded o userRateLimitExceeded, o HTTP 429 con el motivo rateLimitExceeded. La documentación indica reintentar con retroceso exponencial en ambos casos, a diferencia de otros motivos de 403.
-
Paginación de la API REST de GitHub y lectura de sus cabeceras de límite de tasa primario y secundario
La API REST de GitHub pagina mediante una cabecera link con URL rel="next"/"last" y un parámetro per_page limitado a 100 en la mayoría de los endpoints. Los límites primarios se informan en x-ratelimit-limit/remaining/used/reset/resource, tanto los primarios como los secundarios responden con 403 o 429 (los secundarios a veces con retry-after), y un GET condicional autorizado que devuelve 304 no cuenta para el límite primario.
-
Detectar páginas duplicadas en feeds paginados por cursor
Evita los bucles de paginación detectando cursores repetidos y deduplica los registros por identidad estable y revisión.
-
Paginación de la Web API de Slack y gestión de sus niveles de límite de frecuencia por método
La Web API de Slack pagina mediante cursores con response_metadata.next_cursor y el parámetro limit (se recomiendan 100-200; el máximo es 1000, sujeto a cambios y variable según el método), y aplica niveles de límite de frecuencia por método y por espacio de trabajo, de 1+ a 100+ solicitudes por minuto. Al superarlos devuelve HTTP 429 con una cabecera Retry-After en segundos.
Legible por máquina: JSON