Highlights
Klicke jetzt auf einen Request in Activity und du siehst den kompletten Payload. Ein weiterer Klick öffnet ihn wieder im Playground, vorausgefüllt und bereit zum erneuten Ausführen. Wir haben auch eine Klasse von "Proxys" abgefangen, die deinen eigenen Request als gefälschte Response zurückwerfen, und verhindert, dass sie deine Daten verschmutzen.
Neuerungen
Activity → Playground: Jeden Request neu abspielen
Jeder API-Aufruf kommt mit einem X-Foura-Request-Id Header zurück. Dieselbe ID taucht neben dem Request in Activity auf. Klicke auf eine Zeile und du erhältst das volle Bild: wann er lief, welcher Key ihn ausführte, der Request-Body, die Response, die Statuscodes und die Dauer. Klicke auf "Open in Playground" und der Request wird vorausgefüllt in das Formular geladen.
Neu abspielen bedeutete früher, den Request aus dem Gedächtnis nachzubauen. Jetzt hält Activity die Historie und der Playground ist der Rerun-Button.
Ein paar Mechaniken, die du kennen solltest. Wir behalten die letzten 200 Payloads pro API-Key für 24 Stunden. Danach fallen ältere Einträge raus, wenn neue reinkommen. Wenn ein Payload veraltet ist, sagt dir der Dialog das, anstatt ein verwirrendes null oder "(empty body)" anzuzeigen, wie es früher war.
Eine Request-ID, die du auch korrelieren kannst. Logge den X-Foura-Request-Id Response-Header neben deiner eigenen Request-ID auf Client-Seite, und das Finden der passenden Activity-Zeile später erfordert nur ein Einfügen.
Der Capture liegt abseits des Hot-Paths. Dein API-Request wartet nie darauf. Und wenn der Capture-Store nicht erreichbar ist, geht der Aufruf trotzdem durch; der Dialog sagt später nur "no body captured".
Gegen den Response-Body validieren
Der Validate-Bereich des Playgrounds hat Regeln für den Body-Inhalt bekommen. Du kannst sagen "nur erfolgreich, wenn die Response X enthält" oder "fehlschlagen, wenn sie Y enthält", mit mehreren Alternativen, getrennt durch |. 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, den sie zeigen können. Der alte Dialog renderte das als null oder "(empty body)", was leicht als echte leere Response missverstanden werden konnte. Der Dialog unterscheidet jetzt drei Fälle: der Request schlug fehl (mit der tatsächlichen Fehlermeldung), es wurde kein Payload erfasst, oder der Server hat wirklich null Bytes zurückgegeben.
Eine Kleinigkeit, aber sie entfernt diesen wiederkehrenden "Moment, war das die Response oder ein UI-Bug?"-Moment.
Reset-Button im Playground
Bringt das Formular des aktiven Endpoints mit einem Klick auf die Standardwerte zurück. Defaults lassen unblocker und tryJsonData an, da das der 90%-Pfad ist.
Unter der Haube
Honeypot-Proxy-Erkennung
Manche "Proxys" in der Wildnis leiten eigentlich gar nicht weiter. Sie werfen deinen eigenen Request als Klartext-Server-Variablen-Dump (die HTTP-Methode, die Header, der Ziel-Host) zurück, damit der Betreiber sammeln kann, was auch immer drin war. Wir haben denselben Proxy gesehen, der einen Request weiterleitete, den nächsten zurückwarf und den danach mit 502 beantwortete, alles innerhalb einer einzigen Session.
Der Body-Validator erkennt jetzt die Signatur des 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 vom gemeinsamen HTTP-Layer. So wirst du weniger Müllzeilen in Activity sehen und deine Scraper werden nichts aufnehmen, das wie Daten aussieht, aber eigentlich ein Probe ist.
Noch keine Reputationsänderung. Der Proxy bleibt vorerst im Pool. Wir weigern uns nur, dir seine Lüge zurückzugeben.
Also: Wenn ein Request in Activity als harter Fehler getaggt landet, wo er früher wie ein dünner "Erfolg" aussah, ist das der Guard, der ihn abfängt. Besser ein sauberer Fail als ein vergifteter Record.