Processe janelas históricas de forma incremental no seu cliente

Obter chave API

Defina uma janela de consulta, não uma assinatura

Para processar janelas históricas, use from e to com datas ISO nas rotas /v1/search e /v1/posts. Isso permite leituras discretas sem depender de conexão persistente ou entrega instantânea. Reddit Stream API é um arquivo histórico independente, não um serviço oficial ao vivo, SSE ou WebSocket. Cada execução do trabalho envia solicitações separadas. Agendar consultas periódicas não garante atualidade nem demonstra que todos os dados novos apareceram entre execuções.

As datas usam YYYY-MM-DD, aplicam-se a created_utc em UTC e incluem todo o dia indicado em to. Não são datas de entrada no arquivo nem aceitam precisão por hora. Se escolher janelas diárias contíguas, diferencie os dias inicial e final para não criar sobreposição pelo extremo inclusivo. Essa organização local não garante janelas completas ou resultados idênticos quando forem consultadas novamente.

Comece com https://api.redditstreamapi.com/v1/posts?subreddit=datasets&limit=3&page=2, o exemplo da página inicial. Ele pede até três publicações de datasets na segunda página, não um ponto cronológico de continuação. Escolha X-API-Key: <chave> ou Authorization: Bearer <chave> e mantenha o segredo no servidor. A sessão do painel da conta é independente desses cabeçalhos; consulte Obter chave API para preparar o acesso.

Grave uma página antes de avançar o progresso local

Defina um tamanho de página de 1 a 100 conforme o que seu aplicativo consegue processar. O máximo não promete desempenho ideal nem quantidade mínima de registros. page também vai de 1 a 100, e cada solicitação recebe uma página. Confira primeiro o estado HTTP e valide data como lista antes de transformar os campos disponíveis. Uma lista vazia bem-sucedida é um resultado válido.

Conserve resposta, parâmetros e página recebidos antes de atualizar seu ponto de controle local. Esse ponto pertence à aplicação, não é um cursor estável emitido pelo arquivo. Reprocessar uma cópia local não exige outra recuperação; pedir novamente a mesma página pode gerar nova cobrança. A segunda resposta não tem os mesmos registros, campos ou ordem garantidos em relação à primeira. Preserve essa diferença nos relatórios do trabalho.

Leia total com relation: eq expressa um total exato da consulta, gte um limite inferior e unknown a ausência de total confiável, possivelmente null. Não converta desconhecido em zero. Guarde has_more e window_exhausted para descrever os limites encontrados. Ao alcançar a página 100, registre o limite no trabalho; uma fila concluída ou um total exato não certifica download completo.

Diferencie limites, falhas e custos

Os registros seguem _doc, uma ordem interna, não cronologia, relevância ou pontuação. min_score filtra sem ordenar. Você pode ordenar ou remover duplicatas do conjunto recebido localmente, mas isso não demonstra extração exaustiva ou sequência de eventos sem lacunas. parent_id ou link_id presentes permitem associações locais sem conversa completa garantida. A documentação descreve os filtros reais e distingue conteúdo, consulta por id e catálogo de comunidades.

HTTP 400 exige corrigir parâmetros, 401 conferir chave e cabeçalho, 402 consultar saldo no painel e 429 limitar e espaçar novas tentativas. Você pode definir pausas crescentes e um máximo de repetições, sem garantir recuperação posterior. /v1/status é público e gratuito, mas apenas retorna uma declaração estática e confirma que o aplicativo HTTP responde. Não valida chaves, nem mostra saldo ou testa a busca.

Cada recuperação bem-sucedida custa um crédito, mesmo vazia ou repetida. Pedidos inválidos não descontam saldo e falhas do serviço de origem devolvem a reserva. Um tempo de espera esgotado no cliente pode ocultar sucesso cobrado; outro sucesso custa outro crédito. Uma falha local posterior também não anula o sucesso remoto. Consulte os preços para planejar páginas e testes: $1 por 1000 sucessos e recarga paga mínima de $50, sem assinaturas ou expiração de créditos comprados.