Vad är en webhook och hur använder du den?

Webhooks tillåter webbaserade applikationer att interagera genom att använda anpassade återuppringningar.

Genom att använda webhooks kan webbapplikationer automatiskt kommunicera med andra webbappar.

Till skillnad från traditionella system där ett system (subjekt) fortsätter att efterfråga ett annat system (observatör) för vissa data, tillåter webhooks observatören att automatiskt skjuta in data i ämnets system närhelst en händelse inträffar.

Detta eliminerar behovet av konstant övervakning av försökspersonen. Webhooks fungerar helt på Internet och därför måste all kommunikation mellan system ske i form av HTTP-meddelanden.

Använder webhooks

Webhooks förlitar sig på förekomsten av statiska webbadresser som pekar på API:er i ämnets system som måste meddelas när en händelse inträffar i observatörens system. Ett exempel på detta skulle vara en webbapp designad för att samla in och hantera alla beställningar som görs på en användares Amazon-konto. I det här scenariot agerar Amazon som observatör och webbappen Custom Order Management som subjekt.

Istället för att den anpassade webbappen med jämna mellanrum anropar Amazons API:er för att leta efter en skapad beställning, skulle en webhook som skapats i den anpassade webbappen tillåta Amazon att automatiskt skicka en beställning som nyligen skapats i webbappen via en registrerad URL. Därför, för att möjliggöra användningen av webhooks, måste ämnet ha angivna webbadresser som accepterar händelseaviseringar från observatören. Detta minskar en betydande belastning på objektet eftersom HTTP-anrop görs mellan de två parterna endast när en händelse inträffar.

Pollingbaserade system kontra webhookbaserade system

När personens webhook har anropats av observatören, kan personen vidta lämpliga åtgärder med denna nyligen inlämnade data. Vanligtvis görs webhooks via POST-förfrågningar till en specifik URL. POST-förfrågningar låter dig skicka ytterligare information till objektet. Dessutom kan den också användas för att identifiera bland ett antal olika möjliga händelser istället för att skapa separata webhook-URL:er för varje händelse.

Webhook arbetsflöde

För att implementera inkommande webhooks i din applikation måste du utföra följande grundläggande steg:

• Visa en API-slutpunkt på din applikationsserver som accepterar och bearbetar HTTP POST-anrop
• Ge åtkomst till denna slutpunkt för potentiella webhook-användare. API-slutpunkten anropar en datakälla-applikation närhelst de relevanta villkoren är uppfyllda.
• Bearbeta POST-data och returnera ett svar till webhook-samtalsinitiatorn för att indikera status. Detta steg kan vara närvarande eller inte.

Webhooks kontra API:er

Både webhooks och API:er har som mål att etablera kommunikation mellan applikationer. Det finns dock några distinkta fördelar och nackdelar med att använda Webhooks framför API:er för att uppnå applikationsintegration.

Webhooks tenderar att vara bättre lösningar om följande punkter är mer relevanta för det implementerade systemet:

• Om data uppdateras ofta på servern tenderar webhooks att vara bättre lösningar eftersom onödiga API-anrop från klienten till servern elimineras. Enligt resthooks.com går 98,5 % av API-undersökningarna till spillo.
• Webhooks möjliggör bättre lösningar för system som kräver nästan realtidsdatauppdateringar. API-undersökningar körs vanligtvis med bestämda intervaller som kan förhindra att livedata uppdateras. Med webhooks skickas uppdateringar från servern till klienten så fort webhooks utlöses.

Användning av API bör föredras framför webhooks i vissa andra situationer.

Saker att tänka på

De viktiga sakerna att tänka på för att använda API:er på Webhooks är:

• Användning av API:et möjliggör mer anpassning av när man ska polla för data från en server och även hur mycket data som ska pollas från servern. Mängden data som ska pollas styrs av API-undersökningens storlek. Med webhooks bestämmer servern vanligtvis data och när den skickas.
• För system med mycket varierande data (som realtidssystem, IoT-system, etc.), kan API-baserad polling vara ett bättre alternativ eftersom det för varje API-anrop finns en hög sannolikhet för användbara svar.
• Det är möjligt för data som skickas från en server, via en webhook, att ignoreras helt av klienten om REST-slutpunkterna är offline. Om servern inte har en mekanism för att försöka igen sådana misslyckade push, går datauppdateringar helt förlorade.

För att hantera möjligheten att förlora data som skickas från en server när webhook går offline, kan du använda en händelsemeddelandekö för att arkivera dessa samtal. Exempel på plattformar som tillhandahåller sådan funktionalitet inkluderar RabbitMQ o Amazons Simple Queue Service (SQS). Båda är utformade för att fungera som mellanliggande meddelandelagringsmöjligheter som undviker möjligheten att missa ett webhook-samtal.

Ercole Palmeri