Hva er en webhook og hvordan bruker du den?

Webhooks lar nettbaserte applikasjoner samhandle gjennom bruk av tilpassede tilbakeringinger.

Ved å bruke webhooks kan webapplikasjoner automatisk kommunisere med andre web-apper.

I motsetning til tradisjonelle systemer der ett system (subjekt) fortsetter å spørre et annet system (observatør) for noen data, lar webhooks observatøren automatisk skyve data inn i subjektets system når en hendelse inntreffer.

Dette eliminerer behovet for konstant overvåking av forsøkspersonen. Webhooks opererer utelukkende på Internett og derfor må all kommunikasjon mellom systemene foregå i form av HTTP-meldinger.

Bruker webhooks

Webhooks er avhengig av tilstedeværelsen av statiske URL-er som peker til API-er i fagets system som må varsles når en hendelse oppstår i observatørens system. Et eksempel på dette vil være en nettapp designet for å samle inn og administrere alle bestillinger som er lagt inn på en brukers Amazon-konto. I dette scenariet fungerer Amazon som observatør og Custom Order Management Web-appen fungerer som subjekt.

I stedet for å la den tilpassede webappen periodisk ringe Amazons API-er for å se etter en bestilling opprettet, vil en webhook som er opprettet i den tilpassede webappen tillate Amazon å automatisk sende inn en bestilling som nylig er opprettet i webappen via en registrert URL. Derfor, for å muliggjøre bruk av webhooks, må subjektet ha utpekte URL-er som godtar hendelsesvarsler fra observatøren. Dette reduserer en betydelig belastning på objektet siden HTTP-anrop gjøres mellom de to partene bare når en hendelse inntreffer.

Pollingbaserte systemer vs webhookbaserte systemer

Når emnets webhook er oppringt av observatøren, kan emnet iverksette passende tiltak med disse nylig innsendte dataene. Vanligvis gjøres webhooks via POST-forespørsler til en bestemt URL. POST-forespørsler lar deg sende tilleggsinformasjon til objektet. I tillegg kan den også brukes til å identifisere blant en rekke ulike mulige hendelser i stedet for å lage separate webhook-URLer for hver hendelse.

Webhook arbeidsflyt

For å implementere innkommende webhooks på applikasjonen din, må du utføre følgende grunnleggende trinn:

• Vis et API-endepunkt på applikasjonsserveren din som godtar og behandler HTTP POST-anrop
• Gi tilgang til dette endepunktet for potensielle webhook-brukere. API-endepunktet vil kalle opp en datakildeapplikasjon når de relevante betingelsene er oppfylt.
• Behandle POST-dataene og returner et svar til webhook-anropsinitiatoren for å indikere statusen. Dette trinnet kan være til stede eller ikke.

Webhooks vs. APIer

Både webhooks og APIer har som mål å etablere kommunikasjon mellom applikasjoner. Det er imidlertid noen distinkte fordeler og ulemper ved å bruke Webhooks fremfor API-er for å oppnå applikasjonsintegrasjon.

Webhooks har en tendens til å være bedre løsninger hvis følgende punkter er mer relevante for det implementerte systemet:

• Hvis dataene oppdateres ofte på serveren, pleier webhooks å være bedre løsninger ettersom unødvendige API-anrop fra klienten til serveren elimineres. I følge resthooks.com går 98,5 % av API-undersøkelsene til spille.
• Webhooks muliggjør bedre løsninger for systemer som krever nesten sanntidsdataoppdateringer. API-avstemninger kjøres vanligvis med angitte intervaller som kan forhindre at livedata oppdateres. Med webhooks sendes oppdateringer fra serveren til klienten så snart webhooksen utløses.

Bruk av API bør foretrekkes fremfor webhooks i noen andre situasjoner.

Ting å vurdere

De viktige tingene å vurdere for å bruke APIer på Webhooks er:

• Bruk av API gir mulighet for mer tilpasning av når det skal polles etter data fra en server og også hvor mye data som skal polles fra serveren. Mengden data som skal spørres, styres av API-avstemningsstørrelsen. Med webhooks bestemmer serveren vanligvis dataene og når de sendes.
• For systemer med svært variable data (som sanntidssystemer, IoT-systemer osv.), kan API-basert polling være et bedre alternativ siden for hvert API-kall er det stor sannsynlighet for brukbare svar.
• Det er mulig for data sendt fra en server, via en webhook, å bli fullstendig ignorert av klienten i tilfelle REST-endepunktene er offline. I tilfelle serveren ikke har en mekanisme for å prøve slike mislykkede push på nytt, går dataoppdateringer fullstendig tapt.

For å håndtere muligheten for å miste data sendt fra en server når webhook går offline, kan du bruke en hendelsesmeldingskø for å arkivere disse samtalene. Eksempler på plattformer som gir slik funksjonalitet inkluderer Kanin MQ o Amazons Simple Queue Service (SQS). Begge er designet for å fungere som mellomliggende meldingslagringsfasiliteter som unngår muligheten for å gå glipp av et webhook-anrop.

Ercole Palmeri