Mikä on webhook ja miten käytät sitä?

Webhookit mahdollistavat verkkopohjaisten sovellusten välisen vuorovaikutuksen mukautettujen takaisinsoittojen avulla.

Webhookien avulla verkkosovellukset voivat kommunikoida automaattisesti muiden verkkosovellusten kanssa.

Toisin kuin perinteisissä järjestelmissä, joissa yksi järjestelmä (kohde) kyselee jatkuvasti toiselta järjestelmältä (tarkkailijalta) joitakin tietoja, webhookien avulla tarkkailija voi automaattisesti työntää tietoja kohteen järjestelmään aina, kun jokin tapahtuma tapahtuu.

Tämä eliminoi kohteen jatkuvan valvonnan tarpeen. Webhookit toimivat kokonaan Internetissä ja siksi kaiken järjestelmien välisen viestinnän on tapahduttava HTTP-sanomien muodossa.

Webhookien käyttäminen

Webhookit luottavat siihen, että kohteen järjestelmässä on staattisia URL-osoitteita, jotka osoittavat API:ille, joille on ilmoitettava, kun havaitsijan järjestelmässä tapahtuu tapahtuma. Esimerkki tästä on verkkosovellus, joka on suunniteltu keräämään ja hallitsemaan kaikkia käyttäjän Amazon-tilillä tehtyjä tilauksia. Tässä skenaariossa Amazon toimii tarkkailijana ja Custom Order Management Webapp toimii kohteena.

Sen sijaan, että mukautettu verkkosovellus kutsuisi ajoittain Amazon-sovellusliittymiä tarkistaakseen luodun tilauksen, mukautettuun verkkosovellukseen luotu webhook antaisi Amazonille mahdollisuuden lähettää automaattisesti verkkosovelluksessa juuri luodun tilauksen rekisteröidyn URL-osoitteen kautta. Siksi webhookien käytön mahdollistamiseksi kohteella on oltava nimetyt URL-osoitteet, jotka hyväksyvät tapahtumailmoitukset tarkkailijalta. Tämä vähentää objektin merkittävää kuormitusta, koska HTTP-puhelut tehdään kahden osapuolen välillä vain tapahtuman sattuessa.

Äänestyspohjaiset järjestelmät vs. webhook-pohjaiset järjestelmät

Kun tarkkailija kutsuu kohteen webhookia, hän voi ryhtyä tarvittaviin toimiin näiden äskettäin lähetettyjen tietojen kanssa. Yleensä webhookit tehdään POST-pyyntöjen kautta tiettyyn URL-osoitteeseen. POST-pyyntöjen avulla voit lähettää objektiin lisätietoja. Lisäksi sitä voidaan käyttää myös tunnistamaan useiden eri mahdollisten tapahtumien joukosta sen sijaan, että luotaisiin erillisiä webhook-URL-osoitteita kullekin tapahtumalle.

Webhook-työnkulku

Jotta voit ottaa saapuvat webhookit käyttöön sovelluksessasi, sinun on suoritettava seuraavat perusvaiheet:

• Paljasta sovelluspalvelimellasi API-päätepiste, joka hyväksyy ja käsittelee HTTP POST -kutsuja
• Tarjoa pääsy tähän päätepisteeseen mahdollisille webhookin käyttäjille. API-päätepiste kutsuu tietolähdesovellusta aina, kun asiaankuuluvat ehdot täyttyvät.
• Käsittele POST-tiedot ja palauta vastaus webhook-puhelun aloittajalle tilan ilmoittamiseksi. Tämä vaihe voi olla tai ei.

Webhookit vs. API:t

Sekä webhookien että sovellusliittymien tavoitteena on luoda viestintä sovellusten välillä. Webhooksin käyttämisessä sovellusliittymiin verrattuna sovellusintegraation saavuttamiseksi on kuitenkin joitain selviä etuja ja haittoja.

Webhookit ovat yleensä parempia ratkaisuja, jos seuraavat kohdat liittyvät paremmin toteutettuun järjestelmään:

• Jos tietoja päivitetään usein palvelimella, webhookit ovat yleensä parempia ratkaisuja, koska tarpeettomat API-kutsut asiakkaalta palvelimelle jäävät pois. Resthooks.comin mukaan 98,5 % API-tutkimuksista menee hukkaan.
• Webhookit mahdollistavat parempia ratkaisuja järjestelmiin, jotka vaativat lähes reaaliaikaisia ​​tietojen päivityksiä. API-kyselyt suoritetaan tyypillisesti tietyin väliajoin, mikä saattaa estää live-tietojen päivittämisen. Webhookeja käytettäessä päivitykset lähetetään palvelimelta asiakkaalle heti, kun webhook laukeaa.

Sovellusliittymän käyttöä tulee suosia webhookien sijaan joissakin muissa tilanteissa.

Harkittavia asioita

Tärkeitä huomioitavia asioita käytettäessä sovellusliittymiä Webhooksissa ovat:

• API:n avulla voidaan mukauttaa paremmin sitä, milloin palvelimelta pyydetään tietoja ja kuinka paljon tietoja palvelimelta pyydetään. Polloitavien tietojen määrää säätelee API-kyselyn koko. Webhookeilla palvelin päättää yleensä tiedoista ja sen lähetysajankohdan.
• Sovellusliittymäpohjainen kysely voi olla parempi vaihtoehto järjestelmissä, joissa on erittäin vaihtelevia tietoja (kuten reaaliaikaiset järjestelmät, IoT-järjestelmät jne.), koska jokaisella API-kutsulla on suuri todennäköisyys käyttökelpoisille vastauksille.
• On mahdollista, että asiakas jättää kokonaan huomiotta palvelimelta webhookin kautta lähetetyt tiedot, jos REST-päätepisteet ovat offline-tilassa. Jos palvelimella ei ole mekanismia yrittääkseen uudelleen tällaisia ​​epäonnistuneita työntöjä, tietojen päivitykset menetetään kokonaan.

Voit käsitellä palvelimelta lähetettyjen tietojen katoamisen mahdollisuutta, kun webhook siirtyy offline-tilaan, käyttämällä tapahtumaviestijonoa näiden puhelujen arkistointiin. Esimerkkejä tällaisia ​​toimintoja tarjoavista alustoista ovat mm RabbitMQ o Amazonin Simple Queue Service (SQS). Molemmat on suunniteltu toimimaan välittäjänä viestintävälineinä, jotka estävät webhook-puhelun puuttumisen.

Ercole Palmeri