Co jsou webhooky? Snadné vysvětlení a návod

Náš nervový systém je skutečný zázrak.

Jen si vzpomeňte na ten náš mozek... který neustále posílá zprávy do celého našeho těla. Upozorní nás, když potřebujeme jíst, spát nebo sundat ruku ze sporáku.

Dokážete si představit, že byste se museli vědomě ptát svého mozku, jestli máte hlad, zraněný nebo unavený?

Život by byl nezvladatelný.

Dobrou zprávou je, že stejný systém automatizace a upozornění může být také jádrem vašich projektů vývoje webu.

Jedním ze způsobů, jak se tam dostat, je pomocí webhooků. Pravděpodobně je používáte poměrně často, aniž byste věděli, co ve skutečnosti jsou. Dosud si je možná pletete s API.

Pojďme tedy dnes vysvětlit, co jsou webhooky a jak jejich využití zrychlí vaši vývojářskou hru.

Co najdete v tomto příspěvku:

• Definice webhooku

• Příklady webhooku ze skutečného života

• Vývojový tok pro integraci webhooků

• Seznam vývojářských nástrojů

• (mírně) pokročilé funkce

Věř mi dev padawan, změň svůj život, webhooky to změní.

Co jsou webhooky?

Řečeno na rovinu:webhooky představují způsob, jak mezi nimi aplikace automaticky komunikují.

• MailChimp používá webhook k přihlášení uživatelů z vašeho webu k odběru newsletteru.

• Paypal jej používá k tomu, aby sdělil vaší účetní aplikaci, když vám vaši klienti platí.

• Shopify nabízí webhooky, které udržují části vašeho obchodního systému aktuální, takže nemusíte zadávat nové podrobnosti o transakci ručně.

Analogie jdou daleko – nejjednodušší programovací komparativ, na který mohu přijít, je vzor pozorovatele .

Přijímat oznámení prohlížeče například.

Prohlížeč (předmět) upozorní uživatele (pozorovatele), když nastane událost – řekněme příchozí e-mail.

Tato dynamika objektu pozorovatele <> velmi usnadňuje využití asynchronicity v systémech řízených událostmi. Jakmile si toto osvojíte, je mnohem snazší spravovat případy použití se spoustou uživatelských interakcí.

Místo toho, aby uživatel dotazoval server s dotazem, zda se stav změnil, může uživatel pouze říci:"Hej, víš co? Řekni mi, až se stav změní."

Tato interakce je mnohem efektivnější, ale zpočátku je trochu těžší ji nastavit a zamotat hlavu.

Přenesme tyto znalosti do našeho úvodního tématu:webhooky.

Vzor pozorovatele lze implementovat v jakémkoli systému řízeném událostmi , ale webhooky jsou omezeny na, uhodli jste, web . To znamená, že musí komunikovat přes webový protokol – téměř ve všech případech HTTP.

Jak webhook funguje?

Webhook můžete zaregistrovat registrací adresy URL, která vás upozorní, jakmile dojde k dané události. Tento první krok se obvykle provádí buď prostřednictvím uživatelského rozhraní, nebo pomocí rozhraní API.

Vytvořená trasa obsahuje logiku, která se má provést, jakmile k události dojde.

Tímto způsobem systém nemusí znát povahu toho, co je třeba provést, potřebuje pouze sledovat trasy, které má oznámit.

Je to opravdu silné, protože vše zůstává oddělené. Systém B, který obdrží upozornění prostřednictvím zvolené adresy URL, nejenže ví, že došlo k události v jiném systému, ale může na ni také reagovat.

Cesta uchovávající logiku musí být přístupná prostřednictvím požadavku HTTP POST.

Proč konkrétně požadavek POST? Právě proto, že vám dává tu možnost zahrnout tělo do požadavku. Obvykle se jedná o jednoduchý objekt JSON, ale může to být také dokument XML (toto bude vždy uvedeno v dokumentaci webhooku, takže je vždy dobré si jej přečíst, než si začnete hrát).

Přímo v těle najdete informace o tom, k jaké události došlo (viz druhý obrázek níže). Navíc vám řekne, který uživatel to spustil, v jakém čase a další informace specifické pro událost.

Webhooky jsou výkonné, protože mohou být veřejné nebo soukromé.

Soukromé zde znamená, že webhook může zaregistrovat pouze vlastník účtu konkrétního systému. Ve volné přírodě není pro nikoho dostupné sledování událostí na účtu.

Příklad webhooku ze skutečného života

Jak se to všechno přenese do skutečného života?

Pojďme si vysvětlit, jak webhook funguje prostřednictvím konkrétní události Snipcart. V našem nákupním košíku pro vývojáře se webhooky používají k upozornění ostatních aplikací, když se v košíku vyskytnou události, jako je nová objednávka.

Tento příklad zdůrazňuje order.completed událost.

Můžete vidět body , také často nazývaný payload , události zde.

Nebudu teď vytvářet server, který by spouštěl nějakou skutečnou logiku – pouze předpokládám, že nějakou mám. Cílem je porozumět tomu, jak informace proudí a jak jsou spouštěny (nikoli proto, abychom si procvičili naše dovednosti v nastavení serveru).

Představme si, že jste vytvořili cestu HTTP serveru nazvanou /completed a že jste zaregistrovali trasu na řídicím panelu Snipcart:

Takzvaný webhookje trasa obsahující logiku, která se má provést, a přidání trasy do řídicího panelu Snipcartu je to, čemu říkáme "registrace webhooku."

Kritická otázka pro tuto chvíli zní:Jak se to spouští?

Řekněme, že jsem zákazník navštěvující váš obchod. Chvíli bloudím a rozhoduji se, že si produkt koupím. Projdu celým procesem pokladny a objednávka projde.

Server Snipcart může rychle zkontrolovat, zda je registrován nějaký webhook. Zde je /completed trasa musí být oznámena. Chcete-li tak učinit, vytvořili byste požadavek HTTP s tělem obsahujícím informace o objednávce a odeslali byste jej přímo na adresu URL.

Aaa bingo, práce na Snipcartově straně je hotová; upozornění na událost, o kterou jste požádali.

Je to jednoduché, ale síla spočívá v tom, co z tohoto oznámení uděláte.

Jde o to pochopit, že protože můžete svou logiku spustit po oznámení, není statická. Dává vám možnost okamžitě jednat bez jakékoli lidské interakce.

Řekněme order.completed právě nastala událost, můžete vytvořit nový slevový kód pomocí slevového API Snipcart a odeslat tento nový kód prostřednictvím e-mailu zákazníkovi, který právě nakoupil na vašem webu.

Možnosti jsou nekonečné. Můžete dokonce vytvořit přizpůsobitelná trička, na která se po provedení objednávky automaticky vytiskne, řekněme, jméno zákazníka.

Doufám, že začnete chápat sílu webhooků!

Vývojový postup pro integraci webhooků

Nyní, když jste pochopili, jak fungují, zde je můj osobní vývojový tok webhooku, abyste mohli pochopit, jak by vývoj vypadal v reálném životě. Také se s vámi podělím o své oblíbené nástroje, které vám pomohou nastartovat vaši cestu a zároveň vám ušetří spoustu času při vývoji.

Nejdříve:

1. Jak jsem již zmínil, vždy si předem přečtěte dokumentaci k webhooku. Může to znít jako hloupé vodítko, ale upřímně, když se začnete cítit pohodlně, můžete mít pocit, že tento krok můžete přeskočit, a to vás může z dlouhodobého hlediska stát docela dost času.

2. Poté budete chtít zkontrolovat, zda se události skutečně odesílají . RequestBin je k tomu užitečný nástroj. Vytvoříte koncový bod a zaregistrujete jej jako svůj webhook. Nástroj shromáždí všechny požadavky odeslané na tuto trasu, abyste je mohli zkontrolovat. Je to snadný způsob, jak potvrdit, že můžete zaregistrovat trasu a adekvátně přijímat data událostí.

Přitom je dobré zkontrolovat, zda data (tělo požadavku) odpovídají správným objektům, jak je uvedeno v dokumentech. Jakmile bude vše potvrzeno, jste připraveni zašpinit si ruce a začít rozvíjet logiku!

1. Snadný způsob, jak začít, je začít lokálně . Budete moci používat technologii, kterou chcete, a přitom zůstat v kontrolovaném prostředí. Ale rychle narazíte na problém. Logika, kterou implementujete, je ve vašem počítači a vnější svět ji nemůže dosáhnout. Nástroj pro otevření počítače a zachování zabezpečení je ngrok . Upřímně si myslím, že by o tom měl vědět každý vývojář a je to skvělá hodnota, kterou můžete přidat k vašemu švýcarskému armádnímu noži pro vývojáře webu.

2. Nyní obvykle neotevírám veřejnou cestu hned po vybalení, protože moje logika není v době vývoje neprůstřelná. Takže budu požadavky zesměšňovat namísto. K tomu použiji Pošťák , nebo nové dítě v bloku, Insomnia . Oba jsou jednoduchými, ale výkonnými klienty REST, kteří vám umožní ručně vytvořit požadavek HTTP. Místo čekání, že vaši logiku spustí skutečná událost třetí strany, budete ji moci spustit ručně.

Pokud jste použili RequestBin, jak bylo navrženo dříve, budete moci zkopírovat to, co bylo v těle skutečné události, abyste vytvořili svou místní událost. Díky tomu je celý proces mnohem méně promyšlený, protože k testování své logiky budete používat skutečná data. Můžete volně pokračovat ve vývoji a poslat podvrženou žádost přímo od Postmana, jen když si myslíte, že něco máte. Tímto způsobem jsou vaše iterace rychlé a můžete získat zpětnou vazbu, kdykoli budete chtít.

1. Jakmile budete spokojeni s tím, co máte, měli byste použít ngrok k testování s daty v reálném čase. Jakmile je vše v pořádku, právě tehdy chcete hostit svou logiku . Existuje několik způsobů, jak to udělat:

• Hostováním plnohodnotného serveru. Celý proces závisí na použitých technologiích, takže zde nebudu popisovat jak na to.

• Pomocí funkcí bez serveru. Protože logika webhooků je obvykle jednoduchá a stručná, je to pro ně ideální případ. Významnými hráči jsou Webtask.io , AWS Lambda , Google Cloud a Azure .

Rekapitulace vývojových nástrojů webhooku 🛠️

Tento seznam přeskupuje nástroje, které jsem zmínil v minulé části.

• Dokumentace webhooků – specifická pro každý webhook.

• RequestBin — Inspektor požadavků HTTP.

• ngrok — bezpečné místní testování.

• Pošťák nebo Insomnia – klienti REST.

• AWS Lambda, Google Cloud &Azure – funkce bez serveru.

(mírně) pokročilé funkce webhooku

Myslím, že se někam dostáváme, že?

Možná je čas odhalit detaily, které jsem schovával, aniž bych tě příliš zmátl. Jsou to trochu složitější koncepty, ale pokud pokročíte s vývojem webhooku, zkříží vám cestu poměrně rychle.

Dominantní a výkonnou vlastností webhooků je to, že nejen odesílají upozornění prostřednictvím HTTP POST, ale také mohou na stejný požadavek odpovědět dalšími informacemi. Předchozí příklad nepotřeboval odpověď. Pokud bychom však místo toho zaregistrovali, řekněme, webhook pro dopravu, bylo by to bez odpovědi k ničemu.

Například s webhookem pro dopravu Snipcart je trasa informována, když někdo načte sazby za dopravu pro jeho objednávku. Očekává se, že jako odpověď dostanete zpět sazby za dopravu.

Tímto způsobem jste to vy, kdo řídí přepravní sazby prostřednictvím programování bez účasti třetí strany. To by bylo velmi užitečné, pokud byste měli použít různá vlastní pravidla dopravy.

Proces je stejný jako dříve, ale na žádost musíte odpovědět vrácením sazeb, které chcete zobrazit ve svém rozhraní. V tomto případě by sazby musely být definovány v objektu JSON nebo XML. Jakmile počáteční oznamovatel dostane odpověď, mohou být nová data použita v jeho procesu – v tomto případě zobrazení sazeb za dopravu v košíku.

Další charakteristikou webhooku nižší úrovně je ověření . Možná budete chtít ověřit totožnost oznamovatele a je na oznamovateli, aby poskytl způsob, jak to provést. S Snipcartem má každý webhookový požadavek HTTP POST položku záhlaví s názvem „HTTP_X_SNIPCART_REQUESTTOKEN“.

Hodnotu tohoto pole můžete použít, abyste se ujistili, že skutečně pochází z Snipcartu.

Chcete-li tak učinit, museli byste pouze odeslat nový požadavek na server Snipcart na https://app.snipcart.com/api/requestvalidation/{your_request_token} pomocí vašeho klíče API a odpoví vám, zda je token platný.

Ověření není povinné, ale z důvodu bezpečnosti bych jej velmi doporučil.

Úvahy na závěr

Doufám, že z toho vznikne dobře zakulacený úvodní článek o webhoocích. Co opravdu chci, abyste z toho získali, jsou výhody, které mohou přinést vaší vývojové hře. Což se dá shrnout jako přidaná efektivita, výkon pro škálování vašich aplikací a snadný přístup k externím funkcím.

V první části příspěvku jsem použil metaforu vzoru pozorovatele. Ve skutečnosti by se mé příklady blížily vzoru hospoda-sub. Rozdíly nejsou každému zřejmé a je mimo rámec vysvětlovat jejich jemnosti, ale řekl jsem si, že by bylo skvělé sdílet tento skvělý příspěvek na toto téma, pokud vás to zajímá.

Co mi na webhoocích chybělo? Myslíte si, že jsou nezbytnou součástí vývoje webu? Pojďme to probrat v komentářích níže!

Pokud se vám tento příspěvek líbil, věnujte prosím chvilku jeho sdílení na Twitteru .