Integração e API
Long Polling
Mecanismo de comunicação HTTP no qual o servidor adia a resposta até surgir um evento ou expirar um timeout. Long polling evoluiu do polling periódico para reduzir respostas vazias; no Amazon SQS, a espera máxima documentada é 20 s. Exige cliente capaz de reconectar imediatamente e servidor dimensionado para muitas conexões pendentes. A limitação é operacional: cada ciclo continua sendo uma requisição HTTP e pode sofrer timeout de proxy, duplicação ou janela de perda.
🔀 Tipos de Comunicação
HTTP WAIT
Requisição pendente por evento
O cliente envia um GET ou POST e o servidor não responde imediatamente. A conexão permanece aberta até que exista dado, uma condição seja satisfeita ou um prazo seja atingido. Quando recebe a resposta, o cliente processa e abre outra requisição. Esse ciclo cria uma forma de entrega quase em tempo real usando semântica HTTP comum. Em automação, um painel pode aguardar mudança de estado de luzes, presença ou energia sem consultar a cada segundo. O servidor precisa associar a espera ao usuário, ao recurso e ao cursor de eventos. Se a conexão cai depois de o servidor considerar a mensagem entregue, mas antes de o cliente processar, a aplicação precisa recuperar pelo ID. Sem cursor, existe uma janela de perda. Sem deduplicação, a reconexão pode repetir.
QUEUE
Long polling de filas
Serviços de fila usam long polling para evitar retornos vazios. No Amazon SQS, `WaitTimeSeconds` maior que zero habilita o modo e o máximo documentado é 20 s. O consumidor aguarda mensagem e recebe assim que ela fica disponível. Esse desenho reduz chamadas, custo e falsos vazios em comparação com short polling. A mensagem ainda possui visibility timeout, receipt handle e política de exclusão. Long polling não confirma processamento. O consumidor deve concluir a tarefa e só então remover. Se falha, a mensagem volta. Em sistemas locais, o mesmo padrão pode ser usado por um gateway que aguarda comandos numa API de nuvem. O timeout de leitura do SDK deve ser maior que o tempo de espera para não abortar antes do servidor.
CURSOR
Canal de eventos com cursor
Uma API pode receber `since=18420` e manter a conexão aberta até haver evento posterior. A resposta retorna uma lista e o novo cursor. O cliente persiste o cursor e reconecta. Esse modelo oferece recuperação e ordenação melhor que uma resposta sem posição. O cursor deve ser opaco e estável pelo período de retenção. Se expira, a API precisa sinalizar e fornecer ressincronização completa. Em casa inteligente, um aplicativo pode recuperar estados perdidos após ficar offline. Eventos precisam de IDs únicos, timestamp e tipo. O cursor não deve ser calculado apenas por horário, porque relógios podem divergir e dois eventos ter o mesmo instante. Um log monotônico ou token do servidor é preferível.
FALLBACK
Fallback para ambientes sem WebSocket
Firewalls, proxies corporativos ou plataformas antigas podem bloquear Upgrade para WebSocket, enquanto HTTP/1.1 e HTTPS na porta 443 passam. Long polling fornece um fallback. Bibliotecas como Socket.IO historicamente negociam transporte e podem iniciar por polling antes de atualizar para WebSocket. A compatibilidade tem custo: mais cabeçalhos, novas conexões e maior latência entre respostas. HTTP/2 reduz parte do overhead, mas não transforma long polling em stream bidirecional. A escolha precisa ser testada na cadeia real: CDN, WAF, reverse proxy, balanceador e servidor. Sticky session pode ser necessária se o estado de espera fica em memória. Melhor é usar armazenamento compartilhado ou broker.
✅ Vantagens Arquiteturais
⚡
Compatibilidade com infraestrutura HTTP consolidada
A técnica usa métodos, TLS, cookies, autenticação e observabilidade já disponíveis. NGINX, HAProxy, CDNs e bibliotecas HTTP podem encaminhar, desde que timeouts e buffering sejam ajustados. Isso reduz a necessidade de abrir protocolo específico. O benefício é maior em integrações legadas e APIs públicas. A infraestrutura precisa reconhecer conexões longas. Um `proxy_read_timeout` de 60 s suporta espera de 20 s; um gateway com limite de 15 s não. Timeouts devem ter margem para handshake, rede e processamento. O cliente precisa tratar 408, 502, 503 e reset. A compatibilidade nominal com HTTP não garante que todas as camadas aceitem espera prolongada.
⚡
Redução de consultas vazias e consumo desnecessário
Polling a cada 1 s produz 3600 requisições por hora mesmo sem evento. Long polling de 20 s produz no máximo cerca de 180 ciclos vazios por hora por consumidor, e menos quando eventos chegam. Isso reduz CPU, tráfego, logs e custo de API. Em dispositivos a bateria, manter conexão celular ou Wi-Fi também tem custo energético; o ganho depende do rádio e da estratégia. Uma espera longa demais pode ser encerrada por NAT. O servidor deve incluir jitter na reconexão para evitar que milhares de clientes retornem ao mesmo tempo. A otimização precisa medir chamadas, bytes e latência, não apenas contar eventos.
⚡
Entrega rápida sem sessão bidirecional permanente
O servidor responde assim que o evento aparece. A latência pode ficar próxima ao tempo de propagação, melhor que polling com intervalo de 30 s. O cliente não precisa manter protocolo de frames. Para notificações unidirecionais, isso pode bastar. Comandos do cliente usam requisições HTTP separadas. Essa separação é simples de auditar. A limitação é que cada resposta encerra o ciclo e a nova requisição leva tempo. Eventos entre ciclos precisam de cursor. Em alta frequência, WebSocket ou SSE é mais eficiente. O critério de escolha é taxa de eventos, compatibilidade, bidirecionalidade e capacidade operacional.
⚡
Modelo de erro alinhado a códigos HTTP
Autenticação expirada pode retornar 401; limite, 429; indisponibilidade, 503. O cliente reutiliza políticas de retry e refresh. O servidor pode usar `Retry-After`. Isso facilita integração com SDKs. Porém, um HTTP 200 não garante que o conjunto de eventos esteja completo; o cursor e a retenção definem. O timeout pode retornar 200 com lista vazia, 204 ou outra convenção. O contrato precisa ser explícito. Erros de transporte são ambíguos: o servidor pode ter processado. Para comandos, use idempotency key. Para leitura de eventos, use cursor e deduplicação.
⚡
Custo de adoção menor em sistemas pequenos
Uma implementação básica pode usar framework HTTP existente e uma condição assíncrona. Isso custa menos que operar broker e WebSocket gateway separados. O servidor precisa evitar uma thread por conexão. I/O assíncrono, event loop ou servidor com capacidade de conexões pendentes é necessário. Em 10 clientes domésticos, qualquer stack moderno funciona. Em 100 mil, file descriptors, memória, load balancer e fan-out exigem engenharia. A técnica escala, mas não gratuitamente. O projeto deve estimar conexões simultâneas, taxa de eventos e tamanho das respostas.