Hvad er en webhook, og hvordan bruger du den?

Webhooks tillader webbaserede applikationer at interagere ved hjælp af brugerdefinerede tilbagekald.

Brug af webhooks giver webapplikationer mulighed for automatisk at kommunikere med andre web-apps.

I modsætning til traditionelle systemer, hvor et system (emne) bliver ved med at polle et andet system (observatør) for nogle data, tillader webhooks observatøren automatisk at skubbe data ind i emnets system, hver gang en begivenhed indtræffer.

Dette eliminerer behovet for konstant overvågning af emnet. Webhooks opererer udelukkende på internettet og derfor skal al kommunikation mellem systemer foregå i form af HTTP-meddelelser.

Brug af webhooks

Webhooks er afhængige af tilstedeværelsen af ​​statiske URL'er, der peger på API'er i emnets system, som skal underrettes, når en hændelse opstår i observatørens system. Et eksempel på dette ville være en web-app designet til at indsamle og administrere alle ordrer, der er placeret på en brugers Amazon-konto. I dette scenarie fungerer Amazon som observatør, og Custom Order Management Webappen fungerer som emnet.

I stedet for at få den brugerdefinerede webapp til med jævne mellemrum at kalde Amazon API'erne for at kontrollere, om der er oprettet en ordre, vil en webhook, der er oprettet i den brugerdefinerede webapp, give Amazon mulighed for automatisk at indsende en ny oprettet ordre i webappen via en registreret URL. Derfor, for at muliggøre brugen af ​​webhooks, skal emnet have udpegede URL'er, der accepterer begivenhedsmeddelelser fra observatøren. Dette reducerer en betydelig belastning af objektet, da HTTP-kald kun foretages mellem de to parter, når en hændelse opstår.

Afstemningsbaserede systemer vs webhook baserede systemer

Når emnets webhook er ringet op af observatøren, kan emnet tage den passende handling med disse nyligt indsendte data. Typisk udføres webhooks via POST-anmodninger til en specifik URL. POST-anmodninger giver dig mulighed for at sende yderligere oplysninger til objektet. Derudover kan den også bruges til at identificere blandt en række forskellige mulige begivenheder i stedet for at oprette separate webhook-URL'er for hver begivenhed.

Webhook arbejdsgang

For at implementere indgående webhooks på din applikation skal du udføre følgende grundlæggende trin:

• Vis et API-slutpunkt på din applikationsserver, der accepterer og behandler HTTP POST-kald
• Giv potentielle webhook-brugere adgang til dette slutpunkt. API-endepunktet kalder en datakildeapplikation, når de relevante betingelser er opfyldt.
• Behandl POST-dataene og returner et svar til webhook-opkaldsinitiatoren for at angive status. Dette trin kan være til stede eller ikke.

Webhooks vs. API'er

Både webhooks og API'er har som mål at etablere kommunikation mellem applikationer. Der er dog nogle distinkte fordele og ulemper ved at bruge Webhooks frem for API'er for at opnå applikationsintegration.

Webhooks har en tendens til at være bedre løsninger, hvis følgende punkter er mere relevante for det implementerede system:

• Hvis data ofte opdateres på serveren, har webhooks en tendens til at være bedre løsninger, da unødvendige API-kald fra klienten til serveren elimineres. Ifølge resthooks.com går 98,5 % af API-undersøgelser til spilde.
• Webhooks muliggør bedre løsninger til systemer, der kræver næsten realtidsdataopdateringer. API-afstemninger kører typisk med faste intervaller, hvilket kan forhindre live-data i at blive opdateret. Med webhooks sendes opdateringer fra serveren til klienten, så snart webhooks udløses.

Brug af API'et bør foretrækkes frem for webhooks i nogle andre situationer.

Ting at overveje

De vigtige ting at overveje for at bruge API'er på Webhooks er:

• Brug af API'en giver mulighed for mere tilpasning af, hvornår der skal polles for data fra en server og også hvor meget data der skal polles fra serveren. Mængden af ​​data, der skal polles, er styret af API-afstemningens størrelse. Med webhooks bestemmer serveren generelt dataene og hvornår de sendes.
• For systemer med meget variable data (som realtidssystemer, IoT-systemer osv.), kan API-baseret polling være en bedre mulighed, da der for hvert API-kald er stor sandsynlighed for brugbare svar.
• Det er muligt for data sendt fra en server via en webhook at blive fuldstændig ignoreret af klienten i tilfælde af at REST-endepunkterne er offline. Hvis serveren ikke har en mekanisme til at prøve sådanne mislykkede push igen, går dataopdateringer fuldstændig tabt.

For at håndtere muligheden for at miste data sendt fra en server, når webhook går offline, kan du bruge en begivenhedsmeddelelseskø til at arkivere disse opkald. Eksempler på platforme, der leverer en sådan funktionalitet omfatter RabbitMQ o Amazons Simple Queue Service (SQS). Begge er designet til at fungere som mellemliggende beskedlagringsfaciliteter, der undgår muligheden for at gå glip af et webhook-opkald.

Ercole Palmeri