Highlights
Haga clic en cualquier request en Activity y verá el payload completo. Un clic más lo abre de nuevo en Playground, precompletado y listo para ejecutarse otra vez. También detectamos un tipo de "proxy" que devuelve su propio request como una response falsa, y evitamos que contamine sus datos.
What's New
Activity → Playground: vuelva a ejecutar cualquier request
Cada llamada a la API incluye un header X-Foura-Request-Id. El mismo id aparece junto al request en Activity. Haga clic en cualquier fila para ver el panorama completo: cuándo se ejecutó, qué clave lo generó, el cuerpo del request, la response, los códigos de estado y el tiempo que tardó. Haga clic en "Open in Playground" y el request se cargará en el formulario, precompletado.
Antes, volver a ejecutar un request significaba tener que reconstruirlo de memoria. Ahora Activity guarda el historial y Playground es el botón para volver a ejecutarlo.
Algunos detalles de funcionamiento. Guardamos los últimos 200 payloads por clave de API durante 24 horas. Después de eso, las entradas más antiguas se eliminan a medida que entran las nuevas. Cuando un payload ha expirado, el diálogo se lo indica, en lugar de mostrar un confuso null o "(empty body)" como hacía antes.
También puede correlacionar el id del request. Registre el header de response X-Foura-Request-Id junto con su propio id de request en el lado del cliente, y encontrar la fila correspondiente en Activity más tarde solo requerirá pegar el id.
La captura se realiza fuera de la ruta crítica (hot path). Su request de API nunca espera por ella. Y si no se puede acceder al almacenamiento de capturas, la llamada se realiza de todos modos; el diálogo simplemente dirá "no body captured" más tarde.
Validar contra el cuerpo de la response
La sección Validate de Playground ahora cuenta con reglas para el contenido del cuerpo. Puede definir "succeed only if the response contains X" o "fail if it contains Y", con múltiples alternativas separadas por |. Funciona para Single y Proxy. Es útil cuando los códigos de estado no reflejan lo que realmente sucedió.
Los payloads sin cuerpo ahora se explican mejor
Los requests fallidos no tienen un cuerpo de response que mostrar. El diálogo anterior mostraba eso como null o "(empty body)", lo que era fácil de malinterpretar como una response vacía real. Ahora el diálogo distingue tres casos: el request falló (con el mensaje de error real), no se capturó ningún payload o el servidor realmente devolvió cero bytes.
Es un detalle menor, pero elimina esa duda recurrente de "espera, ¿eso fue la response o un error de la interfaz?".
Botón de restablecimiento en Playground
Devuelve el formulario del endpoint activo a sus valores predeterminados con un solo clic. Los valores predeterminados mantienen activados unblocker y tryJsonData, ya que ese es el caso de uso del 90%.
Under the Hood
Detección de proxies honeypot
Algunos "proxies" que se encuentran en la red no reenvían el tráfico en realidad. Devuelven su propio request como un volcado de variables de servidor en texto plano (el método HTTP, los headers, el host de destino) para que el operador pueda recopilar lo que sea que contenga. Hemos visto al mismo proxy reenviar un request, devolver el siguiente y dar un error 502 en el posterior, todo dentro de una misma sesión.
El validador de cuerpo ahora detecta la firma del volcado antes de que la response salga de nuestro edge. Single devuelve un fallo real. Proxy Finder lo reintenta con un proxy diferente. Browser hereda la misma protección de la capa HTTP compartida. Así verá menos filas de basura en Activity y sus scrapers no ingerirán algo que parece datos pero que en realidad es un sondeo.
Aún no hay cambios en la reputación. El proxy permanece en el grupo por ahora. Simplemente nos negamos a devolverle su mentira.
Por lo tanto: si un request aparece en Activity marcado como un fallo definitivo donde antes parecía un "éxito" superficial, es la protección que lo está detectando. Es mejor un fallo limpio que un registro envenenado.