Tema: pagination
-
Paginação e chaves de idempotência na API da Stripe: starting_after, has_more e a janela de 24 horas
Os endpoints de listagem da v1 da Stripe paginam com os parâmetros de cursor mutuamente exclusivos starting_after/ending_before (limit de 1 a 100, padrão 10) e o indicador has_more, e as bibliotecas cliente trazem auxiliares de auto-paginação para percorrer todas as páginas. Requisições POST podem levar uma Idempotency-Key, cujo resultado salvo a Stripe reproduz por cerca de 24 horas, depois das quais as chaves podem ser removidas. Requisições barradas pelo limite de taxa recebem 429 com o cabeçalho Stripe-Rate-Limited-Reason.
-
Testar cursores de continuação depois que a identidade solicitante muda
Verifica a política de visibilidade da aplicação quando um cursor de continuação é reutilizado por outro principal. Este método original trata o cursor como parte de um contexto de consulta cujo significado de segurança precisa ser especificado.
-
Como comprovar o escopo de um inventário paginado antes de fazer alterações em massa
Defina com exatidão quais objetos uma leitura paginada realmente cobriu antes de usá-la como entrada para uma edição em massa, uma proposta de exclusão ou um plano de migração.
-
Seguir o @odata.nextLink do Microsoft Graph e lidar com o throttling 429 e os limites de batch
O Microsoft Graph pagina coleções grandes por meio de uma URL @odata.nextLink, que deve ser seguida como token opaco, sem interpretá-la nem reconstruí-la. Ele aceita tamanhos de página definidos pelo cliente com $top, aplica throttling com HTTP 429 e cabeçalho Retry-After, e limita cada requisição em lote JSON a 20 sub-requisições individuais.
-
Paginação e erros de cota nas APIs do Google: pageToken, 403 rateLimitExceeded e 429
As APIs do Google Workspace, como Calendar e Drive, paginam com o par pageToken/nextPageToken e com maxResults (Calendar) ou pageSize (Drive). O Drive sinaliza sobrecarga de duas formas: HTTP 403 com reason rateLimitExceeded ou userRateLimitExceeded, ou HTTP 429 com reason rateLimitExceeded. A documentação trata ambos como casos para repetir a requisição com backoff exponencial, ao contrário de outros motivos de 403.
-
Paginação da API REST do GitHub e leitura dos cabeçalhos de limite de taxa primário e secundário
A API REST do GitHub pagina por meio de um cabeçalho link com URLs rel="next"/"last" e um parâmetro per_page limitado a 100 na maioria dos endpoints. Os limites primários aparecem em x-ratelimit-limit/remaining/used/reset/resource, ambos os tipos de limite respondem com 403 ou 429 (os secundários às vezes com retry-after), e um GET condicional autorizado que retorna 304 não conta para o limite primário.
-
Detectar páginas duplicadas em feeds paginados por cursor
Como interromper loops de paginação detectando cursores repetidos e, ao mesmo tempo, eliminar registros duplicados por identidade estável e revisão.
-
Paginação da Web API do Slack e tratamento dos níveis de rate limit por método
A Web API do Slack pagina por cursor, usando response_metadata.next_cursor e o parâmetro limit (100-200 recomendado, máximo de 1000, sujeito a mudança e variável por método), e aplica níveis de rate limit por método e por workspace, de 1+ a 100+ requisições por minuto, respondendo com HTTP 429 e um header Retry-After em segundos quando o limite é excedido.
Legível por máquina: JSON