Správa o stave webhookov za rok 2024

V roku 2023 sme sa pozreli na 100 najlepších spoločností API spolu s internými údajmi Svix, aby sme preskúmali, ako často sa osvedčené postupy webhookov implementujú v celom odvetví a aký typ vplyvu majú tieto postupy na spoľahlivosť a škálovateľnosť systémov webhookov.

Tento rok sme sa pozreli na tých istých 100 spoločností, aby sme zistili, či a do akej miery sa zvýšilo prijatie webhookov a osvedčených postupov implementácie. Pozreli sme sa aj na viac ako 100 nových spoločností, ktoré Forbes klasifikoval ako začínajúce v 3 rôznych odvetviach: Fintech, Developer Tools a AI, aby sme porovnali mieru prijatia webhooku v rôznych odvetviach, ako aj podľa štádia spoločnosti.

Sme veľmi radi, že môžeme hlásiť celoplošný nárast v prijímaní webhooku a implementácii osvedčených postupov. Radi by sme si mysleli, že jedným z hlavných faktorov, ktoré k tomuto trendu prispievajú, je vydanie špecifikácie Standard Webook, ktorá načrtáva osvedčené postupy pre odchádzajúce webhooky a pokračujúci dopyt spotrebiteľov webhookov po spoľahlivejších a bezpečnejších webhookoch.

Prijatie webhooku

Minulý rok ponúkalo webhooky 83 zo 100 najlepších API, ktoré sme analyzovali. Keď sme sa tento rok pozreli na rovnakých 100 rozhraní API, došlo k malému nárastu na 85 % adopcie webhooku.

Jedna otázka, na ktorú sme chceli odpovedať v tomto vydaní State of Webhooks, bola, či startupy s väčšou alebo menšou pravdepodobnosťou ponúkajú službu webhooku ako etablovaní poskytovatelia API. Na jednej strane majú startupy tendenciu osvojovať si nové technológie rýchlejšie, ale webhooky majú tendenciu byť funkciou, ktorá sa pridáva po spustení API.

Prevzali sme startupy zo zoznamov Forbes Fintech 50 a AI 50, ako aj z 59 najlepších startupov DevTool od Failory a analyzovali sme ich rovnakým spôsobom, ako sme urobili top 100 API. Je zrejmé, že startupy trochu zaostávajú v prijímaní webhooku, najmä v AI, ktoré majú tendenciu byť viac orientované na spotrebiteľov.

Opakované pokusy

Opätovné pokusy (opätovné odoslanie webhooku, ak pokus zlyhá) sú jednou zo základných súčastí spoľahlivého webhookového systému, takže sme nadšení, že vidíme nárast osvojenia zo 67 % na 73 %.

Zaznamenali sme aj nárast v počte ponúkaných opakovaní pri poklese počtu služieb ponúkajúcich iba 1 opakovanie a náraste v počte služieb ponúkajúcich 5+ opakovaní.

Podobne ako startupy zaostávali v celkovom prijímaní webhooku, zaostávajú aj v prijímaní opakovaných pokusov. Špeciálne pre startupy Devtool je výrazne nižšia miera prijatia, čo bolo neočakávané.

Fintech predstavuje najvyššiu mieru prijatia opakovaných pokusov, čo dáva zmysel vzhľadom na to, aké dôležité je reagovať na finančné udalosti v reálnom čase a nezmeškať/stratiť žiadne transakčné údaje.

Opakovanie: Exponenciálne stiahnutie

Postupné zvyšovanie čakacej doby medzi opakovaniami znižuje riziko zhoršenia akýchkoľvek problémov so serverom, rieši prechodné problémy rýchlym odoslaním prvých niekoľkých pokusov a dáva používateľom dostatok času na opravu zlyhávajúcich koncových bodov.

Prijatie exponenciálneho plánu stiahnutia pre opakované pokusy sa tiež zvýšilo z 25/83 (30 %) na 31/83 (37 %).

Príbeh o exponenciálnom ústupe pre startupy je veľmi podobný celkovému prijatiu opakovaní. Začínajúce podniky v oblasti fintech vedú cestu, pričom startupy Devtool výrazne zaostávajú.

Manuálne pokusy

Na percentuálnom základe bol najväčší nárast prijatia spomedzi všetkých najlepších postupov, ktoré sme analyzovali, implementácia manuálnych opakovaní (+71 %). Samozrejme, bol to najnižší prijatý najlepší postup v správe z roku 2023 a mal najväčší priestor na zlepšenie.

Možnosť manuálneho opakovania správ urýchľuje riešenie problémov. Je rýchlejšie spustiť opakovanie okamžite namiesto čakania na ďalší automatický pokus.

Je to pekný trend, ktorý je možné vidieť a mal by výrazne zjednodušiť život spotrebiteľov webhooku pri riešení problémov so zlyhávajúcimi koncovými bodmi alebo pri potrebe odosielať testovacie udalosti počas počiatočného nastavenia a testovania.

Jedným z najprekvapivejších výsledkov bola miera, s akou začínajúce podniky s umelou inteligenciou prijímajú manuálne pokusy. Náš najlepší odhad, prečo je miera prijatia medzi fintech startupmi taká nízka v porovnaní s ostatnými osvedčenými postupmi, je, že vo finančných systémoch je zvyčajne veľké množstvo správ, takže možnosť zopakovať jednu transakciu je zriedka potrebná.

Keď máte veľké množstvo správ, zvyčajne budete chcieť zopakovať všetky neúspešné správy hromadne alebo v dávkach. Produkty AI majú tendenciu mať nižší objem správ.

Logovanie a monitorovanie

Ďalší veľký percentuálny nárast bol v počte služieb ponúkajúcich protokoly histórie správ. Ide o skvelú funkciu, ktorá používateľom umožňuje samoobslužné riešenie problémov so zlyhávajúcimi koncovými bodmi.

Je to prospešné nielen pre spotrebiteľa, ktorý nemusí čakať na odpoveď od podpory, aby dostal odpovede na otázku, prečo nedostáva očakávané udalosti, ale je to prospešné aj pre poskytovateľa webhooku, pretože v súvislosti s webhookom dostáva podstatne menej žiadostí o podporu. zlyhania.

Problémy sa tiež riešia rýchlejšie, keď si vývojári môžu sami diagnostikovať svoje problémy, takže táto funkcia je výhodná pre všetkých.

Typy udalostí

Ďalším zaujímavým výsledkom je, že prijatie protokolovania a monitorovania správ je pomerne rovnomerné medzi 100 najlepšími poskytovateľmi API v porovnaní so startupmi a naprieč odvetviami.

To naznačuje, že schopnosť samodiagnostiky a odstraňovania porúch nie je jedinečná pre žiadnu konkrétnu oblasť alebo fázu spoločnosti a je to niečo, čo všetci spotrebitelia webhook chcú a z čoho majú veľký úžitok.

Prijatie typu udalosti bolo v podstate rovnaké (93 % oproti 94 %), keďže miera prijatia bola na začiatku taká vysoká. Je to jednoducho preto, že typy udalostí sú základnou funkciou akejkoľvek implementácie webhooku, pretože musíte dať používateľom vedieť, akú udalosť prijímajú.

Je zvláštne, že prijatie typu udalosti bolo pre startupy AI veľmi nízke. V API 100 boli jediné implementácie bez webhookov tie, ktoré mali iba jednu udalosť, takže spoločnosti AI môžu ponúkať iba jednu udalosť.

Overenie správ

Opäť vidíme nárast v prijímaní osvedčených postupov overovania správ (HMACSHA256). Vidíme, že tento nárast pochádza relatívne rovnomerne z poklesu vo všetkých alternatívnych metódach autentifikácie, ale najmä z implementácií, ktoré jednoducho odovzdávali token nosiča.

Prijatie HMACSHA256 je vo všeobecnosti podobné. Odľahlé výsledky pochádzajú z AI 50, kde je odovzdanie tajomstva priamo do hlavičky veľmi populárne. Je zaujímavé, že to vysvetľuje, ako málo z AI 50 neponúka žiadne overenie webhooku.

Overenie správy: Časové pečiatky

Zahrnutie časovej pečiatky ako súčasti hašovaného obsahu pri generovaní podpisov HMAC pomáha predchádzať útokom na opakované prehrávanie. Bez časovej pečiatky ako súčasti podpisu je možné staré správy duplikovať a odoslať znova, čo môže byť veľký problém, ak finančná inštitúcia spracuje rovnakú transakciu dvakrát.

Viac toho istého s časovými pečiatkami v podpise. Etablovaní poskytovatelia API prekonávajú startupy, pokiaľ ide o implementáciu osvedčených postupov.

Dokumentácia

Dobrá dokumentácia je rozhodujúca pre poskytovanie vynikajúcej vývojárskej skúsenosti. To platí najmä pre webhooky, ktoré majú niekoľko „pascí“, do ktorých sa vývojári môžu dostať pri pokuse o implementáciu svojich koncových bodov. Rozsiahla dokumentácia môže používateľom pomôcť vyhnúť sa týmto nástrahám a ušetriť veľa času a frustrácie.

Jedna vec, ktorú vidíme z najlepších webhookových služieb, sú pokyny na testovanie. Patria sem aj tipy na riešenie bežných problémov, ako je napríklad neúspešné overenie podpisu.

Pokiaľ ide o dokumentáciu, startupy sú na rovnakej úrovni ako etablovanejší poskytovatelia webhookov. To je tiež logické, pretože dokumentácia je základom všetkých produktov.

Kľúčovým prvkom, ktorý považujeme za indikátor dobrej dokumentácie webhooku, sú vzorky kódu. To platí pre väčšinu dokumentácie API, ale najmä pre webhooky. Je mimoriadne užitočné mať príklady fungujúcich koncových bodov webhooku, aby používatelia presne pochopili, čo ich koncové body musia robiť a ako to majú robiť.

Spolu so všetkým ostatným, čo sme doteraz v správe videli, sme videli aj ďalšie ukážky kódu. Je to priamy odraz nárastu počtu poskytovateľov, ktorí ponúkajú autentifikáciu podpisu HMAC. Ak poskytovatelia neponúkajú autentifikáciu vôbec alebo ponúkajú jednoduchšie metódy, ako je základné overenie alebo jednoduchá tajná hlavička, je menšia potreba vzorky kódu, pretože implementácia je oveľa jednoduchšia.

Tu väčšina poskytovateľov webhookov, či už zavedených alebo začínajúcich, ponúka svojim používateľom ukážky kódu. Výnimkou sú spoločnosti AI, ktoré zvyčajne neponúkajú podpisy HMAC a prikláňajú sa k tajným hlavičkám na overenie.

Možno, že používatelia AI nie sú tak technicky alebo bezpečnostne vedomí ako spotrebitelia Fintech a Devtool a jednoduchšia metóda overovania je pre ich prípad použitia najlepšia. Zdá sa tiež pravdepodobné, že produkty umelej inteligencie majú základnú používateľskú základňu spotrebiteľov a ich rozhrania API a webhooky sú sekundárnou ponukou pre malé percento ich používateľov, a preto sa investovalo menej úsilia do toho, aby ich služby webhook boli bezpečnejšie/robustnejšie.

Zhrnutie a kľúčové zistenia

S radosťou vám oznamujeme, že po aktualizácii nášho výskumu sme zaznamenali všeobecný nárast v oblasti všeobecného prijatia, ako aj implementácie osvedčených postupov.

Zistili sme, že počet nových používateľov je konzistentný vo všetkých osvedčených postupoch, čo ukázalo, že väčšina zvýšeného prijatia pochádzala z nových implementácií, ktoré dodržiavali väčšinu osvedčených postupov, na rozdiel od existujúcich implementácií, ktoré inovovali ich služby webhook.

Tento rok sme analyzovali ďalších 150 spoločností z 3 rôznych zoznamov top startupov v oblasti Fintech, Devtools a AI, aby sme zistili, či dokážeme nájsť nejaké trendy medzi odvetviami, ako aj rozdiely medzi startupmi a etablovanými poskytovateľmi API.

Vo všeobecnosti sme videli, že etablovaní poskytovatelia API prijímajú webhooky vo vyššej miere a tiež implementujú viac osvedčených postupov. Je to veľmi logické, pretože etablovaní poskytovatelia majú viac zdrojov na investovanie do ponúkania lepšieho riešenia a startupy s väčšou pravdepodobnosťou spúšťajú verzie svojich webhook služieb MVP (minimálny životaschopný produkt).