API-response diff: vergelijk JSON-API-payloads online
Plak links de verwachte respons, rechts de respons die je daadwerkelijk kreeg, en zie elk veld dat is veranderd. Gebouwd voor backend-, QA- en integratiewerk. Niets verlaat je browser.
Wat deze API-response diff-tool is
Een gratis tool die in je browser draait om twee HTTP-API-response bodies te vergelijken. Plak links de JSON uit staging, rechts de JSON uit productie, en de verschillen worden teken voor teken gemarkeerd. De tekst verlaat je machine niet, en dat is van belang omdat echte API-responses vaak e-mailadressen van klanten, sessietokens, interne user-ID's en andere zaken bevatten die je niet naar een externe diff-site wilt uploaden.
Hij is gebouwd voor het moment dat een wankele integratietest in CI omvalt en je op je laptop een Postman-screenshot van een werkende respons hebt en in een CI-log een kapotte respons van de build-runner. Een volledige Pact-contract test opzetten voor een eenmalig onderzoek is overdreven. Twee tekstvlakken, één diff, en je hebt het meestal binnen een minuut teruggebracht tot één enkel veld.
Onder de motorkap is de diff-engine dezelfde als die van onze compare-json-tool. We hebben hem alleen ingekaderd voor de API-testworkflow. Als je responses XML of SOAP-envelopes zijn, regelt onze compare-xml-pagina dat. Als je vrije tekst vergelijkt, zoals een webhook-log of een audittrail, is onze compare-text-tool de juiste plek.
Hoe een API-response diff je daadwerkelijk helpt
Een API-response diff zit in de kloof tussen twee verwante maar verschillende testideeën. Schema-diff voor OpenAPI 3.1 vertelt je wat je contract zegt dat is veranderd: een nieuw optioneel veld, een hernoemde property, een striktere enum. Snapshot-testen (Jest-snapshots, Vitest-snapshots, pytest-snapshot) vertellen je wat je code heeft geproduceerd ten opzichte van een opgeslagen fixture. Deze tool zit aan de runtime-kant. Je geeft hem twee echte response bodies en hij toont je elke byte die verschilt, ongeacht of het schema de wijziging toestaat of of je snapshot-fixture up-to-date is.
Waarom is dat nuttig? Omdat de bugs die het hardst bijten in REST-integratiewerk geen schema-overtredingen zijn. Het zijn subtiele drifts: een serializer die na een Jackson-upgrade stilletjes een datum van ISO-8601 naar een Unix-timestamp omzet, een Marshmallow-schema dat null begint uit te geven in plaats van een ontbrekend veld weg te laten, een DRF-ViewSet dat na een middleware-wijziging het payload in een data-envelope begint te wikkelen. De OpenAPI-spec is niet veranderd. De snapshot is niet bijgewerkt. De tests slaagden geïsoleerd. De integratie ging stuk. Een response-body diff vangt al die gevallen op omdat hij niet om het contract geeft; hij geeft om de bytes.
Vluchtige velden zijn het belangrijkste om in de gaten te houden. Timestamps, request-ID's, trace-ID's, server-gegenereerde UUID's en pagineercursors zullen tussen twee captures van hetzelfde endpoint verschillen, ook als er niets wezenlijks is veranderd. De juiste zet is normaliseren vóór de diff: vervang timestamps door een placeholder, verwijder trace-ID's, sorteer arrays waar de volgorde niet contractueel relevant is. Tools als Pact regelen dat met matchers; in deze tool regel je het door de panelen te bewerken. Het kost tien seconden en haalt de ruisvloer weg.
Een API-response in drie stappen diffen
Twee tekstvlakken, één diff. Geen login, geen upload, geen proxy om te bedraden.
- 1
Vang de eerste respons af
Roep het endpoint aan met curl, httpie, Postman, Insomnia of wat je team ook gebruikt. curl -s https://api.example.com/v1/users/123 | jq is een goede basis omdat jq de JSON netjes opmaakt, wat de diff veel leesbaarder maakt. Kopieer de body (alleen de JSON, geen headers) en plak die in het linkerpaneel. Haal je het uit een CI-log, verwijder dan de timestamp-prefix die de meeste loggers toevoegen, zodat de diff op het echte payload landt.
- 2
Vang de tweede respons af
Roep de vergelijkingsbron aan: de andere omgeving, de andere API-versie, de andere leverancier. Zelfde vorm van capture, zelfde pretty-print-stap. Plak het in het rechterpaneel. Komt één capture uit een opgenomen fixture (vcrpy, pollyjs, MSW, nock) en is de andere live, normaliseer dan eerst de duidelijk vluchtige velden: schrob de request_id, vervang timestamps door een constante en verwijder trace-headers die in de body zijn beland. De resterende diff is het echte signaal.
- 3
Lees de gemarkeerde verschillen
Verwijderingen verschijnen links als rode doorhalingen; toevoegingen rechts in groen. De wijzigings-tellers in elke header zeggen hoeveel afzonderlijke edits de diff vond. Concentreer je eerst op drie dingen: wijzigingen in status-strings, ontbrekende of toegevoegde keys, en wijzigingen van waardetype (string naar number, object naar null). Die drie categorieën dekken bijna elke echte API-regressie. Format- en volgordewijzigingen zijn meestal ruis, tenzij je consumer ervan afhangt.
Wanneer een API-response diff de juiste keuze is
Een wankele integratietest reproduceren
Een test slaagt lokaal en valt om in CI. Je hebt de respons die door je lokale Postman-run is afgevangen en de respons die door de CI-build-agent is afgevangen (de meeste CI-systemen kunnen request/response dumpen met een verbose-flag). Plak beide in de diff-tool. Negen van de tien keer is het verschil omgevingsgerelateerd: een andere feature flag, een verouderde fixture, een tijdzone-offset op de runner. De resterende keer is het een echte bug, en die heb je net teruggebracht tot een specifiek veld.
Een fixture valideren tegen een verse respons
In je repo ligt een ingecheckte fixture-file die voor tests een externe API mockt. De upstream-leverancier heeft net een nieuwe minor-versie uitgebracht. Roep het live endpoint aan met curl, plak die respons naast je fixture en je ziet precies welke velden zijn afgedreven. Dit is de handmatige versie van wat VCR-achtige replay-tools automatiseren. Handig wanneer je één fixture wilt updaten zonder je hele testsuite opnieuw op te nemen.
Achterwaartse compatibiliteit tussen API-versies controleren
Je staat op het punt om v2 van een interne API uit te brengen. Een v1-client draait nog in productie. Roep zowel /v1/orders/42 als /v2/orders/42 aan en diff de responses. Elk verwijderd veld, elke hernoemde key, elke wijziging van waardetype is een breaking change voor de v1-client. Elk nieuw veld is additief en veilig. Het is een arme-mans-versie van een consumer-driven contract test; het schaalt niet naar tientallen endpoints, maar voor een snelle sanity check op één of twee werkt het.
Een serializer-regressie opsporen
Je team heeft Jackson, Marshmallow, DRF of een vergelijkbare serializer-laag geüpgraded. Tests slagen. Vervolgens meldt een downstream-consumer dat zijn parser zich verslikt. Vang de respons van hetzelfde endpoint af op de oude branch en de nieuwe branch en diff ze. Veelvoorkomende vondsten: een datumformaat is van 2026-05-09T10:00:00Z overgegaan op een Unix-timestamp, decimalen hebben hun nullen achteraan verloren, een enum begint als integer in plaats van string te serializeren, of null-velden duiken in het payload op die voorheen werden weggelaten.
Webhook-payloads van twee leveranciers of versies vergelijken
Stripe-webhook V1 en V2 voor hetzelfde event-type lijken bijna identiek en zijn dat absoluut niet. Hetzelfde geldt voor GitHub-webhook event-payloads tussen API-versies, en voor Slack event-subscriptions tussen scopes. Plak een voorbeeld-payload uit elk in de diff-tool om hernoemde velden, verschoven geneste objecten en nieuwe metadata-blokken te zien. Dat is sneller dan beide doc-pagina's van de leverancier naast elkaar lezen, vooral wanneer de docs vaag zijn over welke velden in de praktijk daadwerkelijk verschijnen.
Het klassieke "werkt op staging, kapot op prod" debuggen
De klassieke deploy-hoofdpijn. Hetzelfde client-request retourneert subtiel andere JSON vanuit staging en productie. Vang beide af, plak beide, en het verschil is meestal een config-flag, een ontbrekende feature gate, of een verouderde gecachte respons. Geldt net zo voor multi-region debugging (us-east-1 versus eu-west-1 die andere data teruggeven), CDN-cacheproblemen (Cloudflare heeft een verouderde body gecached) en read-replica-lag waar een schrijfactie nog niet overal is gepropageerd.
Edge cases van API-response diff die de moeite waard zijn
De gevallen waarin een response-body diff het oneens is met je testframework, je OpenAPI-tool of je ogen. Het loont om ze door te lopen voordat je aanneemt dat de diff een echte bug heeft gevonden.
| Topic | What this tool does |
|---|
| Vluchtige velden (timestamps, ID's) | created_at, updated_at, request_id, trace_id, server-gegenereerde UUID's en pagineercursors zullen tussen twee captures altijd verschillen. Normaliseer ze met jq 'del(...)', vervang door een constante, of bewerk ze gewoon weg vóór de diff. Het signaal dat er werkelijk toe doet zit elders. |
|---|
| null versus ontbrekende key | {"foo": null} en {} zijn verschillend in JSON, en veel serializers (Marshmallow, Jackson, System.Text.Json) hebben instellingen die ertussen heen en weer schakelen. De diff brengt dat naar boven. Sommige clients behandelen ze als equivalent en sommige niet; het juiste antwoord is wat jouw consumer doet, en daarom is dit een veelvoorkomende regressiebron na een serializer-upgrade. |
|---|
| Keyvolgorde | RFC 8259 definieert JSON-objecten als ongeordend. Twee semantisch identieke responses met verschillende keyvolgorde verschijnen hier als diff omdat tekstvergelijking volgordegevoelig is. Sorteer beide kanten vooraf met jq --sort-keys als je een volgorde-ongevoelige diff wilt. Pas op voor de zeldzame consumer die wél van volgorde afhangt (sommige signing-flows, sommige legacy-parsers). |
|---|
| Volgorde van arrays | Arrays in JSON zijn geordend, maar veel API's geven arrays terug waarvan de volgorde feitelijk niet contractueel is: een lijst met permissies, een lijst met feature flags, een lijst met webhook-subscriptions. Een diff markeert een herordende array als wijziging, ook als geen consumer er om geeft. Als herordenen in jouw domein onschuldig is, sorteer dan beide kanten vóór de diff op een stabiele key. |
|---|
| Strengheid van JSON.parse | De diff behandelt je input als ondoorzichtige tekst. Als één van je captures een trailing comma, een ongequote key of een commentaar bevat (allemaal verboden in strikte JSON), zal de diff nog steeds werken maar er rommeliger uitzien dan nodig. Haal beide captures eerst door jq . om te herformatteren en ongeldige input af te wijzen. jq gebruikt een strikte RFC 8259-parser. |
|---|
| Response-wrapping (data-envelope versus plat) | Veel API's wikkelen payloads in een {"data": ...}-envelope, soms met meta, links of included ernaast (JSON:API en soortgelijke). Een migratie van plat naar gewikkeld (of andersom) is een breaking change die direct in een diff verschijnt, maar makkelijk over het hoofd wordt gezien in een schema-review omdat het onderliggende record er hetzelfde uitziet. |
|---|
| Wijzigingen in pagineercursors | Cursorgebaseerde paginering gebruikt ondoorzichtige tokens (next_cursor, after, page_token) die zo zijn ontworpen dat ze per call veranderen. Ze verschijnen altijd als diff. Verwijder ze vóór de vergelijking, of vergelijk alleen de inhoud van de data-array en negeer het pagineerblok volledig. |
|---|
| Formaten van foutresponses | Foutbody's zijn het wilde westen. Sommige API's geven een platte {"error": "..."} terug, sommige geven RFC 7807 Problem Details met type, title, status, detail, instance, en sommige geven een leverancier-specifieke vorm. Een migratie naar RFC 7807 vanuit een eigen vorm levert een grote diff op die overwegend een verbetering is; een migratie de andere kant op is een regressie die je vroeg wilt vangen. |
|---|
API-response diff: veelgestelde vragen
Hoe verschilt dit van de ingebouwde diff-functie van Postman?
Postman heeft een respons-vergelijkingsweergave binnen zijn Collection Runner en een Visualize-functie voor individuele responses. Beide zijn prima als je in Postman leeft en je responses al als Postman-historie zijn opgeslagen. Deze tool is leverancier-agnostisch. Je kunt plakken vanuit Postman, Insomnia, curl, httpie, een CI-log, een Stack Overflow-snippet of het Slack-bericht van een collega. Geen account, geen workspace, geen sync. Voor eenmalige vergelijkingen tussen tools is dat sneller. Voor team-gedeelde API-tests binnen één platform is de eigen functie van Postman prima.
Hoe ga ik om met vluchtige velden zoals timestamps en request-ID's?
De pragmatische zet is om vóór de diff te normaliseren. Open beide plak-acties in de panelen en bewerk de vluchtige velden direct: vervang timestamps door een constante string, verwijder de waarden van request_id en trace_id, schrap pagineercursors die per call veranderen. De diff markeert alleen de overgebleven verschillen, en dat zijn degene die er werkelijk toe doen. Voor herhaalde vergelijkingen van hetzelfde endpoint kun je de respons ook door jq met een delete-filter (jq 'del(.meta.request_id)') halen voordat je plakt.
Hoe verschilt dit van een OpenAPI-schema-diff?
Schema-diff vergelijkt contracten: hij vertelt je dat POST /orders een optioneel veld discount_code heeft toegevoegd, of dat de enum status een nieuwe waarde heeft gekregen. OpenAPI-bewuste tools als oasdiff of Spectral doen dit goed. Deze tool vergelijkt echte response bodies. De twee zijn complementair. Schema-diff vangt contractwijzigingen op; response-diff vangt drift tussen contract en realiteit op, en dat is waar serialisatiebugs, omgevingsverschillen en verouderde fixtures zich verstoppen.
Kan hij grote responses aan?
In de praktijk wel, tot enkele duizenden regels netjes opgemaakte JSON per kant. Daarboven wordt de teken-diff met semantische opschoning traag, omdat hij in je browser draait, niet op een server. Voor zeer grote payloads (denk aan een gepagineerde dump van 10.000 records) is de juiste aanpak om de respons in kleinere stukken te knippen per record of per top-level key en elk stuk apart te diffen. Of een structurele diff op de command line draaien met jd of diff <(jq . a.json) <(jq . b.json) voor pure snelheid.
Werkt het voor XML- of SOAP-responses?
Niet direct. Deze pagina is afgestemd op JSON, wat de meeste moderne REST- en webhook-payloads gebruiken. Moet je XML, SOAP-envelopes, RSS of POM-achtige configuratie diffen, dan is onze compare-xml-tool de juiste plek; die behandelt indentatie en namespace-formatting correct. Voor ruwe response bodies die headers en body mengen, of voor plain-text API's (sommige legacy-systemen retourneren nog text/plain), klaart compare-text de klus zonder een structuur op te willen leggen.
Behoudt hij de keyvolgorde of sorteert hij keys?
Hij behoudt de keyvolgorde die je plakt. JSON-objecten zijn formeel ongeordend volgens RFC 8259, dus twee semantisch identieke responses met keys in verschillende volgorde verschijnen in deze tool als diff. Wil je volgorde negeren, normaliseer dan beide kanten eerst via jq --sort-keys of een equivalent. De meeste clients zijn niet afhankelijk van keyvolgorde, dus normaliseren met gesorteerde keys is een veilige standaard voor responsvergelijking; bedenk dat sommige legacy-consumers (oudere XML-naar-JSON-bruggen, bepaalde digitale-handtekeningstromen) wél om volgorde geven.
Privacy en waarom dat telt voor API-responses
API-response payloads bevatten regelmatig zaken die niet mogen uitlekken. E-mailadressen van klanten. Interne user-ID's. Sessietokens. Auth bearer-tokens die per ongeluk in een body-veld zijn beland. Stripe customer-ID's. Webhook-secrets. PII-velden zoals namen, adressen en telefoonnummers. Zoiets in een cloud-gehoste diff-dienst plakken is op zichzelf al een gegevensverwerkingsgebeurtenis, en afhankelijk van je sector kan het je SOC 2-controles, AVG-verwerkingsovereenkomsten of HIPAA Business Associate Agreements schenden. Deze tool draait volledig in je browser. Niets wordt geüpload, gelogd of naar een externe dienst gestuurd. De diff, de markering en de rendering draaien allemaal op je eigen machine. De claim verifiëren is rechttoe rechtaan: open de DevTools van je browser, ga naar het Network-tabblad, plak beide responses en kijk. Er zijn geen uitgaande requests bij het vergelijken. Voor bredere richtlijnen over API-design en -security zijn de API design best practices van Microsoft een solide referentie.