Hvad betyder Webhook?
En webhook er en måde at levere besked om en hændelse på. I stedet for at modtageren gentagne gange spørger, om noget er ændret, sender kildesystemet typisk en HTTP-anmodning til en aftalt adresse. Hændelsen kan eksempelvis være, at en formular er modtaget, eller at en ordre har ændret status.
Webhooks er nyttige til automatisering, men en modtaget besked er ikke det samme som en fuldført forretningsproces. Levering kan blive gentaget, forsinket eller komme i en anden rækkefølge end forventet. Modtagerens design skal tage højde for dette.
Kontrollér og registrér før behandling
Modtageren bør kontrollere, at anmodningen kommer fra den forventede afsender, eksempelvis ved den signaturmetode udbyderen beskriver. Derefter valideres hændelsestype og nødvendige felter. En stabil hændelsesidentifikation kan bruges til at registrere, hvad der allerede er behandlet.
Hvis selve arbejdet tager tid, kan beskeden først lægges sikkert i en kø. Kvitteringen til afsenderen betyder da, at beskeden er modtaget, ikke at alle efterfølgende handlinger er færdige. Denne forskel skal være synlig i driften, så et grønt svar ikke skjuler en voksende kø af ubehandlede sager.
Dubletter og gamle hændelser skal have regler
Gentagen levering bør ikke oprette samme sag to gange. En gammel statusændring bør heller ikke overskrive en nyere, allerede kendt status. Brug kildens dokumenterede identifikatorer og versionering, og læs eventuelt den aktuelle post fra API'et. Et tidsstempel alene er ikke altid en sikker rækkefølge. En periodisk afstemning kan desuden finde poster, som ikke blev opdateret som forventet. Webhooks og læse-API'er kan dermed supplere hinanden.
Et eksempel fra praksis
En projektformular sender en webhook til en intern sagstjeneste. Modtageren kontrollerer afsenderen, registrerer formularens ID og opretter én sag. Hvis afsenderen ikke fik kvitteringen og sender igen, genkendes hændelsen. Et testforløb leverer samme besked tre gange og simulerer en pause i CRM-forbindelsen. Resultatet skal stadig være én sag med en forståelig behandlingsstatus og uden tab af den oprindelige forespørgsel.
Typiske faldgruber
- At stole på en hemmelig URL alene, når udbyderen tilbyder stærkere afsenderkontrol.
- At oprette nye poster for hver levering uden dubletkontrol.
- At kalde en kvitteret webhook for et færdigt workflow.
Det skal I afklare
- Følg udbyderens signatur- og valideringsmetode.
- Gem hændelses-ID, behandlingsstatus og relevant kilde-ID.
- Test dubletter, forsinkelser og forkert rækkefølge.
Spørgsmål og svar
Er en webhook hurtigere end polling?
Den kan reagere, når afsenderen leverer hændelsen, frem for at vente på næste planlagte opslag. Den konkrete forsinkelse og leveringssikkerhed afhænger dog af begge systemer.
Kan vi undvære et API, når vi har webhooks?
Ikke altid. Et API kan være nødvendigt for at hente fulde eller aktuelle oplysninger og afstemme manglende hændelser. Webhooken kan blot være signalet om, at noget skal undersøges.
Kilder og videre læsning
De tekniske begreber bygger på nedenstående kilder. Eksemplerne er illustrative og viser, hvordan I kan arbejde med emnet.
- Stripe: Webhooks ↗Eksempel på signaturkontrol, dubletter og hændelsesrækkefølge.
- CNCF: CloudEvents ↗Fælles beskrivelse af hændelsesdata mellem systemer.