Co je webhook a jak jej používáte?

Webhooky umožňují interakci webových aplikací pomocí vlastních zpětných volání.

Použití webhooků umožňuje webovým aplikacím automaticky komunikovat s jinými webovými aplikacemi.

Na rozdíl od tradičních systémů, kde jeden systém (subjekt) neustále dotazuje jiný systém (pozorovatel) na některá data, webhooky umožňují pozorovateli automaticky vkládat data do systému subjektu, kdykoli dojde k události.

To eliminuje potřebu neustálého sledování subjektem. Webhooky fungují výhradně na internetu a proto veškerá komunikace mezi systémy musí probíhat formou HTTP zpráv.

Použití webhooků

Webhooky spoléhají na přítomnost statických URL odkazujících na API v systému subjektu, které je třeba upozornit, když v systému pozorovatele dojde k události. Příkladem by mohla být webová aplikace určená ke shromažďování a správě všech objednávek zadaných na účtu uživatele Amazon. V tomto scénáři Amazon vystupuje jako pozorovatel a webová aplikace Custom Order Management Webapp vystupuje jako subjekt.

Místo toho, aby vlastní webová aplikace pravidelně volala rozhraní API Amazonu, aby zkontrolovala vytvořenou objednávku, webhook vytvořený ve vlastní webové aplikaci by Amazonu umožnil automaticky odeslat objednávku nově vytvořenou ve webové aplikaci prostřednictvím registrované adresy URL. Proto, aby bylo možné používat webhooky, musí mít subjekt určené adresy URL, které přijímají upozornění na události od pozorovatele. To snižuje významné zatížení objektu, protože volání HTTP se mezi oběma stranami uskutečňují pouze v případě, že dojde k události.

Systémy založené na dotazování vs systémy založené na webhooku

Jakmile pozorovatel zavolá webhook subjektu, může subjekt provést příslušnou akci s těmito nově odeslanými údaji. Webhooky se obvykle provádějí prostřednictvím požadavků POST na konkrétní adresu URL. Požadavky POST umožňují odeslat objektu dodatečné informace. Kromě toho jej lze také použít k identifikaci mezi řadou různých možných událostí namísto vytváření samostatných adres URL webhooku pro každou událost.

Pracovní postup webhooku

Chcete-li do své aplikace implementovat příchozí webhooky, musíte provést následující základní kroky:

• Zveřejněte na svém aplikačním serveru koncový bod API, který přijímá a zpracovává volání HTTP POST
• Poskytněte přístup k tomuto koncovému bodu potenciálním uživatelům webhooku. Koncový bod API zavolá aplikaci zdroje dat, kdykoli jsou splněny příslušné podmínky.
• Zpracujte data POST a vraťte odpověď iniciátorovi volání webhooku, abyste označili stav. Tento krok může nebo nemusí být přítomen.

Webhooky vs. API

Webhooky i rozhraní API mají za cíl navázat komunikaci mezi aplikacemi. Existují však určité výhody a nevýhody používání webhooků oproti rozhraní API k dosažení integrace aplikací.

Webhooky bývají lepšími řešeními, pokud jsou pro implementovaný systém relevantnější následující body:

• Pokud jsou data na serveru často aktualizována, webhooky bývají lepším řešením, protože odpadá zbytečná volání API z klienta na server. Podle resthooks.com jde 98,5 % průzkumů API do odpadu.
• Webhooky umožňují lepší řešení pro systémy, které vyžadují aktualizace dat téměř v reálném čase. Dotazy API se obvykle spouštějí v nastavených intervalech, které mohou bránit aktualizaci živých dat. U webhooků jsou aktualizace odesílány ze serveru klientovi, jakmile je webhook spuštěn.

V některých jiných situacích by mělo mít použití API přednost před webhooky.

Věci ke zvážení

Důležité věci, které je třeba zvážit při používání rozhraní API na webhoocích, jsou:

• Použití API umožňuje více přizpůsobit, kdy se dotazovat na data ze serveru a také kolik dat se dotazovat ze serveru. Množství dat k dotazování se řídí velikostí dotazování API. U webhooků o datech a jejich odeslání obecně rozhoduje server.
• Pro systémy s vysoce variabilními daty (jako jsou systémy v reálném čase, systémy IoT atd.) může být lepší volbou dotazování založené na API, protože pro každé volání API existuje vysoká pravděpodobnost použitelných odpovědí.
• Je možné, aby data odeslaná ze serveru prostřednictvím webhooku byla klientem zcela ignorována v případě, že jsou koncové body REST offline. V případě, že server nemá mechanismus pro opakování takových neúspěšných push, aktualizace dat jsou zcela ztraceny.

Chcete-li se vypořádat s možností ztráty dat odeslaných ze serveru, když webhook přejde do režimu offline, můžete k archivaci těchto hovorů použít frontu zpráv událostí. Příklady platforem, které takovou funkci poskytují, zahrnují RabbitMQ o Služba Amazon Simple Queue Service (SQS). Oba jsou navrženy tak, aby fungovaly jako zprostředkující zařízení pro ukládání zpráv, která zabrání možnosti zmeškat hovor webhooku.

Ercole Palmeri