Highlights
Cliquez maintenant sur n'importe quelle request dans Activity pour voir le payload complet. Un clic de plus l'ouvre à nouveau dans Playground, pré-rempli et prêt à être réexécuté. Nous avons également détecté une catégorie de "proxy" qui renvoie votre propre request sous forme de fausse response, et nous l'avons empêché de polluer vos données.
What's New
Activity → Playground : rejouer n'importe quelle request
Chaque appel API est renvoyé avec un header X-Foura-Request-Id. Le même identifiant apparaît à côté de la request dans Activity. Cliquez sur n'importe quelle ligne pour obtenir une vue d'ensemble : moment de l'exécution, clé utilisée, corps de la request, response, codes d'état et durée de l'exécution. Cliquez sur "Open in Playground" et la request se charge dans le formulaire, pré-remplie.
Auparavant, rejouer une request signifiait la reconstruire de mémoire. Désormais, Activity conserve l'historique et Playground sert de bouton de réexécution.
Quelques détails de fonctionnement à connaître. Nous conservons les 200 derniers payloads par clé API pendant 24 heures. Passé ce délai, les entrées les plus anciennes sont supprimées au fur et à mesure que les nouvelles arrivent. Lorsqu'un payload a expiré, la boîte de dialogue vous en informe, au lieu d'afficher un null ou "(empty body)" déroutant comme auparavant.
Un identifiant de request que vous pouvez également corréler. Enregistrez le header de response X-Foura-Request-Id aux côtés de votre propre identifiant de request côté client, et retrouver la ligne Activity correspondante ne demandera plus qu'un simple copier-coller.
La capture s'effectue en dehors du chemin critique. Votre request API ne l'attend jamais. Et si le stockage des captures est inaccessible, l'appel aboutit tout de même ; la boîte de dialogue affichera simplement "no body captured" plus tard.
Validate against the response body
La section Validate de Playground s'enrichit de règles sur le contenu du corps. Vous pouvez définir "réussir uniquement si la response contient X" ou "échouer si elle contient Y", avec plusieurs alternatives séparées par |. Fonctionne pour Single et Proxy. Utile lorsque les codes d'état masquent la réalité de ce qui s'est passé.
Bodyless payloads explain themselves
Les requests ayant échoué n'ont pas de corps de response à afficher. L'ancienne boîte de dialogue affichait null ou "(empty body)", ce qui pouvait facilement être interprété à tort comme une véritable response vide. La boîte de dialogue distingue désormais trois cas : la request a échoué (avec le message d'erreur réel), aucun payload n'a été capturé, ou le serveur a réellement renvoyé zéro octet.
Un détail, mais qui évite de se demander régulièrement si le résultat est la vraie response ou un bug d'interface.
Reset button in Playground
Rétablit les valeurs par défaut du formulaire de l'endpoint actif en un seul clic. Les valeurs par défaut maintiennent unblocker et tryJsonData activés, car cela correspond à 90 % des cas d'usage.
Under the Hood
Honeypot proxy detection
Certains "proxies" en circulation ne transfèrent pas réellement les requêtes. Ils renvoient votre propre request sous forme de dump de variables serveur en texte brut (la méthode HTTP, les headers, l'hôte cible) afin que l'opérateur puisse en récupérer le contenu. Nous avons vu le même proxy transférer une request, renvoyer la suivante, et retourner une erreur 502 juste après, le tout au cours d'une seule session.
Le validateur de corps détecte désormais la signature de ce dump avant que la response ne quitte notre edge. Single renvoie un échec explicite. Proxy Finder réessaie avec un proxy différent. Browser hérite de la même protection via la couche HTTP partagée. Vous verrez ainsi moins de lignes inutiles dans Activity, et vos scrapers n'ingéreront pas un contenu qui ressemble à des données mais qui est en réalité une sonde.
Pas de changement de réputation pour l'instant. Le proxy reste dans le pool pour le moment. Nous refusons simplement de vous transmettre son mensonge.
Ainsi, si une request apparaît dans Activity avec un statut d'échec critique alors qu'elle ressemblait auparavant à un faux "succès", c'est que la protection l'a interceptée. Mieux vaut un échec net qu'un enregistrement corrompu.