Lim inn responsen du forventet til venstre, responsen du faktisk fikk til høyre, og se hvert felt som er endret. Bygget for backend-, QA- og integrasjonsarbeid. Ingenting forlater nettleseren din.
Et gratis verktøy som kjører i nettleseren for å sammenligne to HTTP-API-responsbody. Lim inn JSON fra staging til venstre, JSON fra produksjon til høyre, og forskjellene fremheves tegn for tegn. Teksten forlater aldri maskinen din, og det betyr noe fordi ekte API-responser ofte inneholder kunders e-postadresser, sesjons-tokens, interne bruker-ID-er og annet du ikke vil laste opp til en tredjeparts diff-side.
Det er bygget for øyeblikket en flakkete integrasjonstest faller i CI, og du har et Postman-skjermbilde av en fungerende respons på laptopen og en CI-logg med en knust respons fra build-runneren. Å sette opp en full Pact-contract test for en engangsundersøkelse er overdrevent. To tekstfelt, en diff, og du kan vanligvis snevre inn problemet til ett enkelt felt på under et minutt.
Under panseret er diff-motoren den samme som driver vårt compare-json-verktøy. Vi har bare rammet det inn for API-test-flyten. Hvis responsene dine er XML eller SOAP-envelopes, håndterer compare-xml-siden vår det. Hvis du sammenligner fri tekst som en webhook-logg eller et audit trail, er compare-text-verktøyet vårt riktig sted.
En API-respons-diff sitter i gapet mellom to beslektede, men distinkte test-ideer. Schema-diff for OpenAPI 3.1 forteller deg hva kontrakten din sier har endret seg: et nytt valgfritt felt, en omdøpt property, en strengere enum. Snapshot-testing (Jest-snapshots, Vitest-snapshots, pytest-snapshot) forteller deg hva koden din produserte mot en lagret fixture. Dette verktøyet sitter på runtime-siden. Du gir det to ekte responsbody, og det viser deg hver byte som skiller seg, uavhengig av om skjemaet tillater endringen eller om snapshot-fixturen din er oppdatert.
Hvorfor er det nyttig? Fordi bugene som biter hardest i REST-integrasjonsarbeid ikke er skjemabrudd. Det er subtile drifter: en serializer som stille byttet en dato fra ISO-8601 til en Unix-timestamp etter en Jackson-oppgradering, et Marshmallow-skjema som begynte å sende null i stedet for å utelate et manglende felt, et DRF ViewSet som etter en middleware-endring begynte å pakke payloaden inn i en data-envelope. OpenAPI-specen endret seg ikke. Snapshotten ble ikke oppdatert. Testene gikk gjennom isolert. Integrasjonen knakk. En diff på responsbody fanger alle disse, fordi den ikke bryr seg om kontrakten; den bryr seg om bytene.
Volatile felt er det viktigste å holde øye med. Timestamps, request-ID-er, trace-ID-er, server-genererte UUID-er og pagineringscursorer vil avvike mellom to capture av samme endpoint, selv når ingenting meningsfullt har endret seg. Det riktige trekket er å normalisere før diff: bytt timestamps med en placeholder, fjern trace-ID-er, sorter arrayer der rekkefølgen ikke er kontraktsmessig viktig. Verktøy som Pact løser det med matchers; i dette verktøyet løser du det ved å redigere feltene. Det tar ti sekunder og fjerner støygulvet.
To tekstfelt, en diff. Ingen innlogging, ingen opplasting, ingen proxy å koble.
Treff endpointet med curl, httpie, Postman, Insomnia eller hva teamet ditt bruker. curl -s https://api.example.com/v1/users/123 | jq er et godt utgangspunkt fordi jq formaterer JSON pent, noe som gjør diffen mye lettere å lese. Kopier body (kun JSON, ikke headers) og lim inn i venstre felt. Hvis du henter fra en CI-logg, fjern timestamp-prefikset som de fleste loggers legger til, slik at diffen lander på selve payloaden.
Treff sammenligningskilden: det andre miljøet, den andre API-versjonen, den andre leverandøren. Samme form for capture, samme pretty-print-steg. Lim inn i høyre felt. Hvis ett capture er fra en innspilt fixture (vcrpy, pollyjs, MSW, nock) og det andre er live, normaliser de åpenbart volatile feltene først: skrubb request_id, bytt timestamps med en konstant og fjern trace-headers som har lekket inn i body. Den gjenværende diffen er det reelle signalet.
Slettinger vises som rødt overstreket til venstre; tillegg som grønt til høyre. Endringstellerne i hver header sier hvor mange separate redigeringer diffen fant. Fokuser først på tre ting: endringer i status-strenger, manglende eller tillagte nøkler og endringer av verditype (string til number, object til null). De tre kategoriene dekker nesten enhver reell API-regresjon. Format- og rekkefølgeendringer er vanligvis støy med mindre consumeren din avhenger av dem.
En test går gjennom lokalt og faller i CI. Du har responsen som det lokale Postman-kjøret fanget og responsen som CI-build-agenten fanget (de fleste CI-systemer kan dumpe request/response med et verbose-flag). Lim inn begge i diff-verktøyet. Ni av ti ganger er forskjellen miljørelatert: et annet feature flag, en utdatert fixture, en tidssone-offset på runneren. Den tiende er en ekte bug, og du har akkurat lokalisert den til et bestemt felt.
Repoet ditt har en innsjekket fixture-fil som mocker et tredjeparts-API i testene. Upstream-leverandøren slapp akkurat en ny minor-versjon. Treff live-endpointet med curl, lim inn den responsen ved siden av fixturen din, og du ser nøyaktig hvilke felt som har drevet. Dette er den manuelle versjonen av det VCR-lignende replay-verktøy automatiserer. Nyttig når du vil oppdatere én fixture uten å spille inn hele testsuiten på nytt.
Du er i ferd med å slippe v2 av et internt API. En v1-klient finnes fortsatt i produksjon. Treff både /v1/orders/42 og /v2/orders/42 og diff responsene. Ethvert fjernet felt, enhver omdøpt nøkkel, enhver endring av verditype er en breaking change for v1-klienten. Ethvert nytt felt er additivt og trygt. Det er en fattigmannsutgave av en consumer-driven contract test; den skalerer ikke til dusinvis av endpoints, men til en rask sanity check på en eller to fungerer den.
Teamet ditt oppgraderte Jackson, Marshmallow, DRF eller et lignende serialiseringslag. Testene består. Etterpå melder en downstream-consumer at parseren deres setter seg fast. Fang samme endpoint-respons på den gamle branchen og den nye branchen og diff dem. Vanlige funn: et datoformat skiftet fra 2026-05-09T10:00:00Z til en Unix-timestamp, desimaler mistet etterstilte nuller, en enum begynte å serialisere som integer i stedet for string, eller null-felt dukket opp i payloaden som tidligere ble utelatt.
Stripe-webhook V1 og V2 av samme event-type ser nesten identiske ut og er det slett ikke. Det samme gjelder GitHub-webhook-event-payloads mellom API-versjoner og Slack-event-subscriptions mellom scopes. Lim inn et eksempel-payload fra hver i diff-verktøyet for å se omdøpte felt, flyttede nestede objekter og nye metadata-blokker. Det er raskere enn å lese begge leverandørenes doc-sider side om side, særlig når dokumentasjonen glir over hvilke felt som faktisk dukker opp i praksis.
Den klassiske deploy-hodepinen. Samme klient-request returnerer subtilt forskjellig JSON fra staging og produksjon. Fang begge, lim inn begge, og forskjellen er som regel et config-flag, en manglende feature gate eller en utdatert cachet respons. Det gjelder like mye for debugging på tvers av regioner (us-east-1 mot eu-west-1 som returnerer forskjellige data), CDN-cache-problemer (Cloudflare cachet en utdatert body) og read-replica-forsinkelse der en skriving ikke har propagert overalt.
Tilfellene der en respons-body-diff er uenig med hva testrammeverket ditt, OpenAPI-verktøyet ditt eller øynene dine ville sagt. Verdt å skumme før du antar at diffen har funnet en ekte bug.
| Topic | What this tool does |
|---|---|
| Volatile felt (timestamps, ID) | created_at, updated_at, request_id, trace_id, server-genererte UUID-er og pagineringscursorer vil alltid avvike mellom to capture. Normaliser dem med jq 'del(...)', bytt med en konstant, eller bare rediger dem ut før diff. Signalet du faktisk bryr deg om bor et annet sted. |
| null vs manglende nøkkel | {"foo": null} og {} er forskjellige i JSON, og mange serializers (Marshmallow, Jackson, System.Text.Json) har innstillinger som veksler mellom dem. Diffen får det fram. Noen klienter behandler dem som ekvivalente, andre ikke; det rette svaret er hva consumeren din gjør, og det er derfor det er en hyppig regresjonskilde etter en serializer-oppgradering. |
| Nøkkelrekkefølge | RFC 8259 definerer JSON-objekter som uordnede. To semantisk identiske responser med forskjellig nøkkelrekkefølge vises her som diff fordi tekstsammenligning er rekkefølgeavhengig. Sortér begge sider på forhånd med jq --sort-keys hvis du vil ha rekkefølge-uavhengig diff. Pass på den sjeldne consumeren som faktisk avhenger av rekkefølge (visse signeringsflyter, visse legacy-parsers). |
| Array-rekkefølge | Arrayer i JSON er ordnede, men mange API-er returnerer arrayer hvis rekkefølge faktisk ikke er kontraktsmessig: en liste over permissions, en liste over feature flags, en liste over webhook-subscriptions. En diff markerer en omsortert array som endring, selv når ingen consumer bryr seg. Hvis omsortering er harmløs i ditt domene, sortér begge sider på en stabil nøkkel før diff. |
| JSON.parse-strenghet | Diffen behandler input som ugjennomsiktig tekst. Har en av captureene dine et trailing-komma, en usitert nøkkel eller en kommentar (alle ulovlige i streng JSON), vil den fortsatt diffe, men se mer støyende ut enn nødvendig. Kjør begge captures gjennom jq . først for å reformatere og avvise ugyldig input. jq bruker en streng RFC 8259-parser. |
| Respons-innpakking (data-envelope vs flat) | Mange API-er pakker payloads inn i en {"data": ...}-envelope, av og til med meta, links eller included ved siden av (JSON:API og lignende). En migrasjon fra flat til innpakket (eller omvendt) er en breaking change som dukker opp i en diff umiddelbart, men er lett å overse i en skjema-gjennomgang fordi den underliggende recorden ser lik ut. |
| Endringer av pagineringscursor | Cursor-basert paginering bruker ugjennomsiktige tokens (next_cursor, after, page_token) som er designet til å endre seg ved hvert kall. De vises alltid som diff. Fjern dem før sammenligning, eller sammenlign bare innholdet i data-arrayen og ignorer pagineringsblokken helt. |
| Formater for feilresponser | Feil-body er det ville vesten. Noen API-er returnerer en flat {"error": "..."}, noen returnerer RFC 7807 Problem Details med type, title, status, detail, instance, og noen returnerer en leverandørspesifikk form. En migrasjon til RFC 7807 fra en egen form gir en stor diff som hovedsakelig er en forbedring; en migrasjon den andre veien er en regresjon verdt å fange tidlig. |
Postman har en respons-sammenligningsvisning inne i Collection Runner og en Visualize-funksjon for enkeltresponser. Begge er bra hvis du lever i Postman og responsene dine allerede er lagret som Postman-historikk. Dette verktøyet er leverandøruavhengig. Du kan lime inn fra Postman, Insomnia, curl, httpie, en CI-logg, et Stack Overflow-snippet eller en kollegas Slack-melding. Ingen konto, ingen workspace, ingen sync. Til engangs-sammenligninger på tvers av verktøy er det raskere. Til team-delte API-tester innen én plattform er Postmans egen funksjon grei.
Det pragmatiske trekket er å normalisere før diff. Åpne begge innliminger i feltene, og rediger så de volatile feltene direkte: bytt timestamps med en konstant streng, fjern verdiene for request_id og trace_id, slett pagineringscursorer som endrer seg ved hvert kall. Diffen fremhever bare de gjenværende forskjellene, og det er dem som faktisk betyr noe. Til gjentatte sammenligninger av samme endpoint kan du også sende responsen gjennom jq med et delete-filter (jq 'del(.meta.request_id)') før du limer inn.
Skjema-diff sammenligner kontrakter: den forteller deg at POST /orders har lagt til et valgfritt felt discount_code, eller at enumet status har fått en ny verdi. OpenAPI-bevisste verktøy som oasdiff eller Spectral gjør dette godt. Dette verktøyet sammenligner faktiske responsbody. De to utfyller hverandre. Skjema-diff fanger kontraktendringer; respons-diff fanger driften mellom kontrakt og virkelighet, som er der serialiseringsbugs, miljøforskjeller og utdaterte fixtures gjemmer seg.
I praksis ja, opp til noen tusen linjer formatert JSON per side. Utover det blir tegn-diffen med semantisk opprydning treg, fordi den kjører i nettleseren din, ikke på en server. For svært store payloads (tenk en paginert dump på 10 000 records) er den rette tilnærmingen å skjære responsen i mindre biter per record eller per top-level-nøkkel og diffe hver bit separat. Eller kjøre en strukturell diff fra kommandolinjen med jd eller diff <(jq . a.json) <(jq . b.json) for ren hastighet.
Ikke direkte. Denne siden er trimmet for JSON, som er det de fleste moderne REST- og webhook-payloads bruker. Hvis du må diffe XML, SOAP-envelopes, RSS eller POM-lignende konfigurasjon, er compare-xml-verktøyet vårt rett sted; det håndterer innrykk og namespace-formatering korrekt. Til rå responsbody som blander headers og body, eller til plain-text-API-er (noen legacy-systemer returnerer fortsatt text/plain), gjør compare-text jobben uten å forsøke å påtvinge en struktur.
Det bevarer nøkkelrekkefølgen du limer inn. JSON-objekter er formelt uordnede ifølge RFC 8259, så to semantisk identiske responser med nøkler i forskjellig rekkefølge vises som diff i dette verktøyet. Vil du ignorere rekkefølge, normaliser begge sider først ved å sende dem gjennom jq --sort-keys eller tilsvarende. De fleste klienter avhenger ikke av nøkkelrekkefølge, så normalisering med sorterte nøkler er en trygg default for respons-sammenligning; vær oppmerksom på at noen legacy-consumers (eldre XML-til-JSON-broer, visse digitale signaturflyter) faktisk avhenger av rekkefølge.
API-respons-payloads inneholder regelmessig ting du ikke vil få lekket. Kunders e-postadresser. Interne bruker-ID-er. Sesjons-tokens. Auth-bearer-tokens som ved en feil havnet i et body-felt. Stripe-kunde-ID-er. Webhook-secrets. PII-felt som navn, adresser og telefonnumre. Å lime en slik inn i en sky-hostet diff-tjeneste er i seg selv en databehandlingshendelse, og avhengig av bransje kan det bryte SOC 2-kontrollene dine, GDPR-databehandlingsavtaler eller HIPAA Business Associate Agreements. Dette verktøyet kjører helt i nettleseren din. Ingenting lastes opp, logges eller sendes til noen tredjepartstjeneste. Diff, fremheving og rendering kjøres alle på maskinen din. Å verifisere påstanden er enkelt: åpne nettleserens DevTools, bytt til Network-fanen, lim inn begge responsene og se. Det er ingen utgående requests når du sammenligner. For bredere veiledning om API-design og sikkerhet er Microsofts API design best practices en solid referanse.