Destaques
Clique em qualquer request em Activity agora e você verá o payload completo. Mais um clique e ele é reaberto no Playground, preenchido previamente, pronto para ser executado novamente. Também detectamos uma classe de "proxy" que ecoa seu próprio request de volta como uma response falsa, e impedimos que ela poluísse seus dados.
Novidades
Activity → Playground: reproduza qualquer request
Cada chamada de API retorna com um header X-Foura-Request-Id de response. O mesmo id aparece ao lado do request em Activity. Clique em qualquer linha e você terá a visão completa: quando foi executado, qual chave o originou, o corpo do request, a response, os status codes e o tempo que levou. Clique em "Open in Playground" e o request será carregado no formulário, preenchido previamente.
Antes, reproduzir um request significava reconstruí-lo de cabeça. Agora, o Activity mantém o histórico e o Playground funciona como o botão de reexecução.
Alguns detalhes de funcionamento. Mantemos os últimos 200 payloads por chave de API por 24 horas. Depois disso, as entradas mais antigas são descartadas à medida que novas chegam. Quando um payload expira, a caixa de diálogo avisa você, em vez de exibir um null confuso ou "(empty body)" como costumava fazer.
Um request id que você também pode correlacionar. Registre o header de response X-Foura-Request-Id junto ao seu próprio request id no lado do cliente, e encontrar a linha correspondente em Activity depois exigirá apenas um colar.
A captura ocorre fora do caminho crítico (hot path). Seu request de API nunca espera por ela. E se o armazenamento de captura estiver inacessível, a chamada ainda assim é concluída; a caixa de diálogo apenas exibirá "no body captured" mais tarde.
Valide contra o corpo da response
A seção Validate do Playground ganhou regras de conteúdo do corpo. Você pode definir "sucedido apenas se a response contiver X" ou "falhar se contiver Y", com múltiplas alternativas separadas por |. Funciona para Single e Proxy. Útil quando os status codes mentem sobre o que realmente aconteceu.
Payloads sem corpo explicam a si mesmos
Requests que falharam não têm um corpo de response para exibir. A caixa de diálogo antiga renderizava isso como null ou "(empty body)", o que era facilmente interpretado de forma errada como uma response vazia real. Agora, a caixa de diálogo distingue três casos: o request falhou (com a mensagem de erro real), nenhum payload foi capturado ou o servidor realmente retornou zero bytes.
Um detalhe pequeno, mas que elimina aquele momento recorrente de "espera, isso foi a response ou um bug de UI?".
Botão de reset no Playground
Retorna o formulário do endpoint ativo para os padrões com um único clique. Os padrões mantêm unblocker e tryJsonData ativados, já que esse é o caminho em 90% dos casos.
Sob o Capô
Detecção de proxy honeypot
Alguns "proxies" por aí não fazem o encaminhamento de verdade. Eles ecoam seu próprio request de volta como um dump de variáveis de servidor em texto puro (o método HTTP, os headers, o host de destino) para que o operador possa coletar o que estiver contido nele. Já vimos o mesmo proxy encaminhar um request, ecoar o seguinte e retornar 502 no próximo, tudo dentro de uma única sessão.
O validador de corpo agora detecta a assinatura do dump antes que a response saia da nossa borda (edge). O Single retorna uma falha honesta. O Proxy Finder tenta novamente com um proxy diferente. O Browser herda a mesma proteção da camada HTTP compartilhada. Assim, você verá menos linhas de lixo em Activity, e seus scrapers não vão ingerir algo que parece dado, mas na verdade é uma sondagem.
Nenhuma mudança de reputação por enquanto. O proxy continua no pool por hora. Nós apenas nos recusamos a retornar a mentira dele para você.
Portanto: se um request chegar em Activity marcado como uma falha grave onde antes parecia um "sucesso" superficial, essa é a proteção agindo. Melhor uma falha limpa do que um registro envenenado.