Highlights
Klicke jetzt auf einen Request in Activity und du siehst den vollständigen Payload. Ein weiterer Klick öffnet ihn wieder im Playground, vorausgefüllt und bereit für die erneute Ausführung. Wir haben außerdem eine Art von „Proxy“ abgefangen, die deinen eigenen Request als gefälschte Response spiegelt, und sie daran gehindert, deine Daten zu verunreinigen.
Was ist neu
Activity → Playground: Jeden Request wiederholen
Jeder API-Call liefert einen X-Foura-Request-Id-Header zurück. Dieselbe ID wird neben dem Request in Activity angezeigt. Klicke auf eine beliebige Zeile und du erhältst das vollständige Bild: wann er ausgeführt wurde, welcher Key ihn ausgelöst hat, den Request-Body, die Response, die Statuscodes und die benötigte Zeit. Klicke auf „Open in Playground“ und der Request wird vorausgefüllt in das Formular geladen.
Früher bedeutete ein Replay, den Request aus dem Gedächtnis neu aufzubauen. Jetzt speichert Activity den Verlauf und Playground ist der Button zum erneuten Ausführen.
Einige Details zur Funktionsweise. Wir bewahren die letzten 200 Payloads pro API-Key für 24 Stunden auf. Danach fliegen ältere Einträge raus, wenn neue hinzukommen. Wenn ein Payload abgelaufen ist, teilt dir das der Dialog mit, anstatt wie früher ein verwirrendes null oder „(empty body)“ anzuzeigen.
Eine Request-ID, die du ebenfalls korrelieren kannst. Protokolliere den X-Foura-Request-Id-Response-Header clientseitig neben deiner eigenen Request-ID, und das Finden der passenden Activity-Zeile erfordert später nur noch ein Einfügen.
Das Erfassen liegt außerhalb des Hot Paths. Dein API-Request wartet nie darauf. Und falls der Erfassungsspeicher nicht erreichbar ist, geht der Call trotzdem durch; der Dialog zeigt später einfach „no body captured“ an.
Validierung gegen den Response-Body
Der Validate-Bereich im Playground hat Regeln für den Body-Inhalt erhalten. Du kannst festlegen: „nur erfolgreich, wenn die Response X enthält“ oder „fehlschlagen, wenn sie Y enthält“, wobei mehrere Alternativen durch | getrennt werden können. Funktioniert für Single und Proxy. Nützlich, wenn Statuscodes darüber lügen, was tatsächlich passiert ist.
Bodylose Payloads erklären sich selbst
Fehlgeschlagene Requests haben keinen Response-Body, der angezeigt werden könnte. Der alte Dialog stellte das als null oder „(empty body)“ dar, was leicht als echte leere Response missverstanden werden konnte. Der Dialog unterscheidet nun drei Fälle: Der Request ist fehlgeschlagen (mit der tatsächlichen Fehlermeldung), es wurde kein Payload erfasst oder der Server hat tatsächlich null Bytes zurückgegeben.
Eine Kleinigkeit, aber sie beseitigt den wiederkehrenden Moment des Zweifels: „Warte, war das die Response oder ein UI-Bug?“.
Reset-Button im Playground
Setzt das Formular des aktiven Endpoints mit einem Klick auf die Standardwerte zurück. Die Standardwerte lassen unblocker und tryJsonData aktiviert, da dies der 90%-Pfad ist.
Unter der Haube
Honeypot-Proxy-Erkennung
Einige „Proxies“ da draußen leiten Requests gar nicht weiter. Sie spiegeln deinen eigenen Request als Klartext-Dump der Servervariablen zurück (die HTTP-Methode, die Header, der Ziel-Host), damit der Betreiber die darin enthaltenen Daten abgreifen kann. Wir haben erlebt, dass derselbe Proxy einen Request weiterleitet, den nächsten spiegelt und beim übernächsten einen 502-Fehler liefert – alles innerhalb einer einzigen Session.
Der Body-Validator erkennt nun die Signatur dieses Dumps, bevor die Response unsere Edge verlässt. Single gibt einen ehrlichen Fehler zurück. Proxy Finder versucht es mit einem anderen Proxy erneut. Browser erbt denselben Schutz von der gemeinsamen HTTP-Schicht. Du siehst also weniger Müll-Zeilen in Activity und deine Scraper lesen nichts ein, was wie Daten aussieht, aber eigentlich ein Scan ist.
Bisher gibt es keine Änderung der Reputation. Der Proxy bleibt vorerst im Pool. Wir weigern uns lediglich, dir seine Lüge zurückzugeben.
Also: Wenn ein Request in Activity als harter Fehler markiert landet, wo er früher wie ein scheinbarer „Erfolg“ aussah, dann hat der Schutz gegriffen. Besser ein sauberer Fehlschlag als ein korrumpierter Datensatz.