Verzoeken vergelijken (Diff)

“Waarom lukte het deze keer wel en de vorige keer niet?” “Voor hetzelfde endpoint, welke regel verschilt precies tussen het geslaagde en het mislukte verzoek?” Zet twee verzoeken/antwoorden naast elkaar en het antwoord ligt meteen op tafel. Dit is de snelste manier om intermitterende productieproblemen te onderzoeken, verschillen te reproduceren en wijzigingen te verifiëren.

1. Hoe je het gebruikt: in twee stappen klaar

Klik met rechts op een willekeurig stuk verkeer en kies “Markeren als vergelijking A”.
Klik met rechts op een ander stuk verkeer en kies “Vergelijken met A”.

Er verschijnt meteen een venster met een vergelijking naast elkaar, dat elk verschil tussen de twee regel voor regel markeert.

2. Waar je naar kijkt: zowel verzoeken als antwoorden zijn te vergelijken

Bovenaan het venster schakel je met één tik tussen het vergelijken van het verzoek of het antwoord. De twee kanten zijn A en B, elk met een label (methode · host · status), zodat je in één oogopslag ziet welke twee je vergelijkt. De vergelijking bestrijkt het hele bericht:

Startregel: de verzoekregel (methode / adres / protocol) of de antwoordregel (protocol / statuscode)
Alle request- / responseheaders
Request body / response body (automatisch opgemaakt en daarna regel voor regel vergeleken, met JSON, XML en formulieren allemaal goed leesbaar)

3. Verschillen in één oogopslag

Eerst opmaken, dan regel voor regel diffen: JSON, XML en formulieren worden eerst geformatteerd en dan regel voor regel vergeleken, zodat de velden die echt zijn veranderd meteen opvallen, zonder dat ze verdrinken in opmaakruis zoals regeleindes en inspringing.
Kleurcodering per regel: toevoegingen (+), verwijderingen (−) en wijzigingen (~) worden elk gemarkeerd, met de A-kant rood en de B-kant groen, en gewijzigde regels naast elkaar getoond.
Aantal verschillen: bovenaan staat een samenvatting van het aantal “toegevoegde / verwijderde / gewijzigde” regels, zodat je de omvang kent.
Het meldt wanneer ze identiek zijn: als de twee overeenkomen, staat er duidelijk “identiek”, zodat je niet zelf regel voor regel hoeft te controleren; als een kant geen inhoud heeft of nog niet ontsleuteld is, wordt dat direct gemeld in plaats van je te laten wachten.
Met regelnummers: elke kant heeft zijn eigen regelnummers om de exacte positie te vinden.

Vergelijkingsvenster naast elkaar: bovenaan schakelen tussen verzoek / antwoord, A / B elk met een label en regelnummers, kleurcodering per regel, en rechtsboven een samenvatting van toegevoegde / verwijderde / gewijzigde regels

4. Waar het echt uitblinkt: vergelijken over sessies en bronnen heen

De twee records die worden vergeleken hoeven niet uit dezelfde capture-sessie te komen, en hoeven ook niet op hetzelfde moment te zijn vastgelegd; zolang je ze in de interface hebt gezien, kun je ze erbij halen om te vergelijken:

Succes vs. falen: zet een geslaagd en een mislukt verzoek naast elkaar en zie meteen welke header, welke parameter of welk deel van de body verschilt.
Handmatig gebouwd vs. echt: vergelijk een verzoek dat is opnieuw verstuurd/verzonden en daarna vastgelegd in de Verzoeksamensteller met een eerder vastgelegd echt verzoek, om te verifiëren “of ik het correct heb opgebouwd” en “of de handtekening consistent wordt berekend.”
Voor en na een wijziging: vergelijk na het wijzigen van de server / client het oude en nieuwe verzoek om te bevestigen of de wijziging is doorgevoerd en of er neveneffecten zijn.
Over omgevingen heen: bekijk de retourwaarden van hetzelfde endpoint in de test- en productieomgeving naast elkaar om configuratie- of dataverschillen snel te lokaliseren.

Dit is ook waar het veel krachtiger is dan het inspecteren van één verzoek: verschillen worden blootgelegd door vergelijking in plaats van door te vertrouwen op geheugen en het blote oog. Gewone tools kunnen vaak alleen binnen dezelfde sessie, met het oog stukje bij beetje vergelijken.

5. Typische toepassingen

Intermitterende storingen onderzoeken: geslaagd verzoek vs. mislukt verzoek, om het afwijkende veld vast te pinnen.
Integratie afstemmen: het verzoek dat de client daadwerkelijk verstuurde vs. de API-documentatie / het verwachte verzoek.
Regressieverificatie: het verschil in hetzelfde verzoek / antwoord voor en na een wijziging bevestigen.
Handtekeningen debuggen: een handmatig gebouwd ondertekend verzoek vs. een echt verzoek, verifiëren of elk onderdeel consistent is.

Terug naar Proxy-capture · Gerelateerd: Verzoeken samenstellen en opnieuw versturen