Wat is 'n webhook en hoe gebruik jy dit?

Webhooks laat webgebaseerde toepassings toe om interaksie te hê deur die gebruik van pasgemaakte terugbelopings.

Die gebruik van webhooks laat webtoepassings toe om outomaties met ander webtoepassings te kommunikeer.

Anders as tradisionele stelsels waar een stelsel (onderwerp) aanhou om 'n ander stelsel (waarnemer) vir sekere data te stem, laat webhooks die waarnemer toe om outomaties data in die onderwerp se stelsel in te stoot wanneer 'n gebeurtenis plaasvind.

Dit skakel die behoefte aan konstante monitering deur die proefpersoon uit. Webhooks werk geheel en al op die internet en daarom moet alle kommunikasie tussen stelsels in die vorm van HTTP-boodskappe plaasvind.

Gebruik webhooks

Webhooks maak staat op die teenwoordigheid van statiese URL's wat na API's in die onderwerp se stelsel wys wat in kennis gestel moet word wanneer 'n gebeurtenis in die waarnemer se stelsel plaasvind. 'n Voorbeeld hiervan is 'n webtoepassing wat ontwerp is om alle bestellings wat op 'n gebruiker se Amazon-rekening geplaas word, te versamel en te bestuur. In hierdie scenario tree Amazon op as die waarnemer en die Custom Order Management Webapp dien as die onderwerp.

In plaas daarvan dat die pasgemaakte webtoepassing die Amazon API's periodiek bel om te kyk vir 'n bestelling wat geskep is, sal 'n webhaak wat in die pasgemaakte webtoepassing geskep word, Amazon toelaat om outomaties 'n bestelling wat nuut in die webtoepassing geskep is via 'n geregistreerde URL in te dien. Daarom, om die gebruik van webhooks moontlik te maak, moet die onderwerp aangewese URL's hê wat gebeurteniskennisgewings van die waarnemer aanvaar. Dit verminder 'n aansienlike las op die voorwerp aangesien HTTP-oproepe slegs tussen die twee partye gemaak word wanneer 'n gebeurtenis plaasvind.

Polling-gebaseerde stelsels vs webhook-gebaseerde stelsels

Sodra die proefpersoon se webhook deur die waarnemer geroep is, kan die proefpersoon die toepaslike aksie neem met hierdie nuut ingediende data. Tipies word webhooks gedoen via POST-versoeke na 'n spesifieke URL. POST-versoeke laat jou bykomende inligting na die voorwerp stuur. Boonop kan dit ook gebruik word om tussen 'n aantal verskillende moontlike gebeurtenisse te identifiseer in plaas daarvan om aparte webhook-URL's vir elke gebeurtenis te skep.

Webhook werkvloei

Om inkomende webhooks op jou toepassing te implementeer, moet jy die volgende basiese stappe uitvoer:

• Stel 'n API-eindpunt op jou toepassingbediener bloot wat HTTP POST-oproepe aanvaar en verwerk
• Verskaf toegang tot hierdie eindpunt vir potensiële webhook-gebruikers. Die API-eindpunt sal 'n databrontoepassing oproep wanneer ook al aan die relevante voorwaardes voldoen word.
• Verwerk die POST-data en stuur 'n antwoord aan die webhook-oproep-inisieerder om die status aan te dui. Hierdie stap kan of mag nie teenwoordig wees nie.

Webhooks vs. API's

Beide webhooks en API's het die doel om kommunikasie tussen toepassings te vestig. Daar is egter 'n paar duidelike voordele en nadele van die gebruik van Webhooks bo API's om toepassingsintegrasie te bewerkstellig.

Webhooks is geneig om beter oplossings te wees as die volgende punte meer relevant is vir die geïmplementeerde stelsel:

• As die data gereeld op die bediener opgedateer word, is webhooks geneig om beter oplossings te wees aangesien onnodige API-oproepe van die kliënt na die bediener uitgeskakel word. Volgens resthooks.com gaan 98,5% van API-opnames tot niet.
• Webhooks maak beter oplossings moontlik vir stelsels wat byna intydse data-opdaterings benodig. API-peilings loop gewoonlik met vasgestelde intervalle wat kan verhoed dat regstreekse data opgedateer word. Met webhooks word opdaterings vanaf die bediener na die kliënt gestuur sodra die webhook geaktiveer word.

Die gebruik van die API moet in sommige ander situasies bo webhooks verkies word.

Dinge om te oorweeg

Die belangrike dinge om te oorweeg vir die gebruik van API's op Webhooks is:

• Die gebruik van die API maak voorsiening vir meer aanpassing van wanneer om vir data van 'n bediener te stem en ook hoeveel data om van die bediener af te stem. Die hoeveelheid data wat gepeil moet word, word beheer deur die API-peilinggrootte. Met webhooks besluit die bediener gewoonlik die data en wanneer dit gestuur word.
• Vir stelsels met hoogs veranderlike data (soos intydse stelsels, IoT-stelsels, ens.), kan API-gebaseerde peiling 'n beter opsie wees, aangesien daar vir elke API-oproep 'n hoë waarskynlikheid van bruikbare antwoorde is.
• Dit is moontlik dat data wat vanaf 'n bediener gestuur word, via 'n webhook, heeltemal deur die kliënt geïgnoreer word ingeval die REST-eindpunte vanlyn is. As die bediener nie 'n meganisme het om sulke mislukte stoot weer te probeer nie, is data-opdaterings heeltemal verlore.

Om die moontlikheid te hanteer om data te verloor wat van 'n bediener af gestuur is wanneer die webhook vanlyn gaan, kan jy 'n gebeurtenisboodskapwaglys gebruik om daardie oproepe te argiveer. Voorbeelde van platforms wat sulke funksionaliteit verskaf, sluit in Konyn MQ o Amazon se Simple Queue Service (SQS). Albei is ontwerp om op te tree as tussengangerboodskapbergingsfasiliteite wat die moontlikheid vermy om 'n webhook-oproep te mis.

Ercole Palmeri