Rozdiel spočíva predovšetkým v načasovaní
Redakcia o 10:14 zverejní zmenu poradenského pracoviska. Webová stránka musí okamžite ukázať nové telefónne číslo, vyhľadávač vo vlastnom portáli má obnoviť index a zrozumiteľná jazyková verzia potrebuje neskôr odbornú kontrolu. Tieto následky patria k rovnakej zmene, no nemusia sa všetky spracovať v rovnakom okamihu.
Webhook je správa, ktorú jeden systém odošle druhému bezprostredne po udalosti. Redakčný systém napríklad oznámi: Táto stránka bola zverejnená. Prijímajúci systém potom môže načítať a spracovať presne tento obsah. Nečaká na ďalší všeobecný beh a ani sa neustále nepýta na nové zmeny.
Pri dávkovom spracovaní sa zhromaždí viacero úloh a vykonajú sa spoločne. Každý večer sa napríklad môžu do správy skontrolovať všetky stránky zmenené v daný deň. Takýto beh nie je okamžitý, ale dá sa dobre plánovať. Dokáže postupne spracovať veľké množstvo a poskytnúť výsledok ako ucelený prehľad. Spracovanie pritom má známy začiatok a rozpoznateľný koniec.
Webhooky sú vhodné pre jednotlivé dôležité udalosti
Webhooky majú zmysel, keď včasná reakcia prináša zjavný úžitok. Po zverejnení výstrahy má aplikácia dostať rovnaký aktuálny obsah. Po stiahnutí stránky má táto stránka zmiznúť z interného vyhľadávania. Správa zakaždým vzniká konkrétnym úkonom a týka sa jasne určiteľného obsahu.
Pre redakciu pôsobí tento postup okamžite. Schváli príspevok a o chvíľu uvidí novú verziu v pripojenom kanáli. Túto rýchlosť si však nemožno zamieňať so zaručenou súčasnosťou. Chyby siete, údržba alebo preťažená protistrana môžu spracovanie oneskoriť. Systém musí takéto prerušenia zvládnuť.
Webhook nemá spúšťať každá uložená zmena. Automaticky uložený koncept ešte nie je dôležitý pre verejné vyhľadávanie. Zmysluplné udalosti vychádzajú z viditeľného významu: zverejnené, podstatne aktualizované, stiahnuté alebo vymazané. Pripojené systémy tak dostávajú menej správ a môžu jednoznačnejšie spracovať dôležité zmeny stavu. Interné opravy preklepov možno podľa potreby riešiť inak než nové fakty.
Dávkové spracovanie je vhodné pre veľké množstvo a pevné termíny
Väčší beh je vhodný, keď sa podľa rovnakých pravidiel spracúva veľa obsahov. Organizácia môže napríklad chcieť každú noc skontrolovať všetky zverejnené stránky, či na nich nechýba údaj o dátume kontroly. Pre čitateľov je málo podstatné, či bude výsledok k dispozícii o 02:00 alebo 02:20. Okamžitá správa po každej malej úprave by bola zbytočne náročná.
Aj úplné opätovné vytvorenie možno zámerne vykonať spoločne. Po zmene vyhľadávacieho systému môže byť potrebné znova načítať 80 000 stránok. Jednotlivé webhooky by obsah spoľahlivo neopísali, pretože zmena sa týka aj nezmenených stránok. Dávkový beh začína so známym množstvom a dokumentuje, ktoré stránky sa úspešne spracovali.
Pevný čas uľahčuje plánovanie zaťaženia. Opisy obrázkov, návrhy prekladov alebo rozsiahle kontroly kvality vyžadujú výpočtový čas a externé služby. Nočný beh môže túto prácu obmedziť bez spomalenia publikovania v redakčnom systéme. Jeho trvanie je tak predvídateľnejšie pre prevádzku aj poskytovateľov služieb. Naliehavý obsah napriek tomu potrebuje rýchlejšiu cestu, ak by dlhé čakanie viedlo k nesprávnym informáciám.
Najprv rozhoduje prípustné oneskorenie
Najdôležitejšia otázka znie: Ako dlho môže pripojený systém zobrazovať starý stav? Pri výstrahe pred nepriaznivým počasím môžu rozhodovať minúty. Pri mesačnom hodnotení kvality textu zvyčajne neprekáža jeden deň. Jasný časový údaj pomôže viac než všeobecná požiadavka, aby bolo každé spracovanie čo najrýchlejšie.
Potom je dôležitý rozsah typickej zmeny. Ak sa zvyčajne publikuje jedna stránka, webhook ju môže presne pomenovať. Ak sa pravidelne menia celé súbory, plánovaný beh je prehľadnejší. Import nových lokalít so 4 000 záznamami by nemal nekontrolovane spustiť 4 000 súčasných následných úloh.
Súčasťou rozhodnutia sú aj následky výpadku. Ak sa správa stratí, v aplikácii môže zostať neaktuálne telefónne číslo. Ak zlyhá nočná správa, redakcia ju môže ráno spustiť znova. Prípustné oneskorenie treba výslovne dohodnúť pre každý pripojený kanál. Čím väčšia je bezprostredná škoda, tým dôležitejšie sú rýchle opakovania, viditeľné upozornenia a dodatočné porovnanie celého obsahu.
Správa webhooku zostáva malá a jednoznačná
Dobrá správa uvádza, čo sa stalo, ktorého obsahu sa to týka a kedy udalosť vznikla. Dopĺňa ju jedinečné číslo udalosti a verzia formátu správy. Prijímajúci systém si potom môže cez chránené rozhranie načítať úplné aktuálne údaje. Správa tak zostáva prehľadná a zbytočne neobsahuje celý článok.
Tento postup tiež zabraňuje tomu, aby oneskorená správa rozšírila starý text. Predstavme si, že redakcia krátko po sebe dvakrát opraví rovnaké telefónne číslo. Prvá správa pre poruchu príde neskôr než druhá. Ak si protistrana načíta aktuálny stav, napriek tomu dostane naposledy schválenú verziu, nie obsah oneskorenej správy.
Osobné alebo dôverné údaje nepatria bez potreby do správy. Protokoly, chybové hlásenia a administračné rozhrania často ukladajú údaje webhookov na dlhší čas. V mnohých prípadoch stačí identifikátor obsahu a druh udalosti. Oprávnená protistrana si ďalšie údaje načíta až vtedy, keď ich skutočne potrebuje spracovať. Aj technické chybové hlásenie tak zostane bez zbytočného odborného obsahu.
Opakované správy sú bežným prípadom
Ak prijímajúca strana nepotvrdí doručenie správy, východiskový systém ju odošle znova. Prvá správa už možno bola spracovaná, ale jej potvrdenie sa stratilo. Protistrana preto musí vedieť prijať rovnakú udalosť viackrát bez dvojitého zverejnenia príspevku alebo dvojitého objednania rovnakého prekladu.
Pomáha pri tom jedinečné číslo udalosti. Ak sa toto číslo už úspešne spracovalo, systém môže opakovanie potvrdiť a preskočiť. Je to spoľahlivejšie než porovnávanie časov alebo názvov. Dve rôzne zmeny môžu nastať takmer súčasne a názov sa môže zmeniť, hoci stále ide o rovnaký obsah.
Ani poradie nie je vždy isté. Oznámenie o zverejnení môže prísť až po oznámení o neskoršej oprave. Čísla verzií alebo načítanie aktuálneho obsahu zabránia tomu, aby zvíťazil starší stav. Pre redakcie to znamená, že viditeľný stav musí byť správny aj vtedy, keď technické správy prejdú nepokojnou cestou. O platnej verzii preto nesmie rozhodovať iba dátum prijatia.
Príjemca musí overiť pôvod
Na verejne dostupnú adresu webhooku sa v zásade môžu obrátiť aj neoprávnené osoby. Protistrana preto nesmie dôverovať správe iba preto, že prišla na očakávanú cestu. Bežne sa používa digitálny podpis vypočítaný z obsahu a spoločného tajného kľúča. Príjemca ho vypočíta znova a obe hodnoty porovná.
Prenos prebieha cez HTTPS, aby boli obsah a prístupové údaje počas cesty chránené. Tajný kľúč nepatrí do zdrojového kódu, verejnej dokumentácie ani textu správy. Ukladá sa bezpečne, sprístupňuje sa len potrebným službám a pravidelne sa obnovuje. Staré kľúče sa po riadenom prechodnom období musia stať neplatnými.
Časová pečiatka navyše obmedzuje, ako dlho sa správne podpísaná správa prijíma. Zaznamenané volanie tak nemožno ľubovoľne neskôr zopakovať. Chybové odpovede nemajú útočníkom prezrádzať interné podrobnosti. Vlastnému tímu však zostane dostatok údajov na cielené preverenie odmietnutého podpisu alebo zastaraného formátu správy. Nápadné prístupy sa obmedzujú a zrozumiteľne zaznamenávajú na bezpečnostnú kontrolu. Platia pre ne primerané a jasne zdokumentované lehoty uchovávania.
Veľký beh potrebuje sledovateľný stav
Pri 20 000 stránkach je dávkový beh len zriedka úplne úspešný alebo úplne neúspešný. Niektoré obsahy môžu mať neplatné údaje, zatiaľ čo zvyšok sa spracuje správne. Beh preto musí pri každej položke zaznamenať, čo sa podarilo a čo treba skúsiť znova. Jediná chybná stránka nesmie zablokovať všetky nasledujúce.
Treba zohľadniť obmedzenia externých služieb. Rozhranie môže povoľovať iba určitý počet požiadaviek za minútu. Beh potom rozdelí množstvo na primerané časti a po prestávke pokračuje. Ukladá svoj postup, aby po opätovnom spustení nezačínal znova od prvej stránky a zbytočne neopakoval už zaplatenú prácu.
Pre redakciu je zrozumiteľný výsledok dôležitejší než dlhý technický protokol. Musí rozpoznať, ktorého behu sa problém týka, koľko obsahov je hotových a ktoré stránky potrebujú odbornú pomoc. Oznámenie ako 37 chýb nestačí. Priradenie k názvu stránky, adrese a konkrétnej príčine mení chybu na spracovateľnú úlohu. Úspešne zopakované úlohy následne zmiznú z otvoreného redakčného zobrazenia.
Webhooky často dopĺňa plánovaný beh
Webhooky a dávkové spracovanie sa navzájom nevylučujú. Spravodajský portál môže nové príspevky okamžite oznámiť svojmu vyhľadávaču a v noci porovnať celý obsah. Rýchla cesta udržiava dôležité zmeny aktuálne. Plánovaný beh nájde udalosti, ktoré chýbajú pre poruchu, nesprávne nastavenie alebo dočasne vypnutú protistranu.
Aj zrozumiteľná jazyková verzia môže potrebovať oba časy. Keď sa zmení odborná stránka, webhook okamžite vytvorí úlohu pre príslušnú redakciu. Skontrolovaná verzia sa nenahradí automaticky. Denná správa navyše ukáže všetky otvorené úlohy, ich lehoty a obsahy, pri ktorých chýba prepojenie s východiskovou stránkou.
Rozhodujúci je jasný zdroj platného stavu. Webhook oznamuje zmenu, pravidelné porovnanie potvrdzuje aktuálny obsah. Ak poskytujú odlišné údaje, nesmie náhodne zvíťaziť naposledy vykonaný proces. Rozhodujúci zostáva publikujúci systém a pripojené systémy s ním zosúladia svoj stav. Toto pravidlo musí zostať jednoznačne zdokumentované aj po zmene systému.
Prevádzka musí zostať zrozumiteľná pre ľudí
Technická spoľahlivosť sa prejavuje vo viditeľnej informácii. Tímy majú vedieť, ako dlho prenos bežne trvá a odkedy sa oneskorenie hlási. Upozornenie pomenuje dotknutý kanál a obsah, nie iba interný názov procesu. Redakcia tak môže posúdiť, či návštevníci práve vidia zastaraný stav.
Každý postup potrebuje zodpovedné pracovisko. Môže znova odoslať zaseknutú správu, pokračovať v dávkovom behu alebo zastaviť nesprávne zverejnenie. Zároveň musí byť zrejmé, kedy sa vyžaduje odborná zodpovednosť. Technický tím dokáže preniesť súbor, no nemôže rozhodnúť, či bola zmenená podmienka nároku obsahovo vysvetlená správne.
Vhodné riešenie teda vychádza z obsahu, času a možnej škody. Webhooky rýchlo reagujú na jednotlivé udalosti. Dávkové behy spracúvajú plánovateľné množstvá a porovnávajú obsah. Spoločne pokrývajú aktuálne zmeny aj úplnosť obsahu. Ak sa od začiatku zohľadnia opakovania, bezpečnosť a zrozumiteľné hlásenia, pripojené webové stránky a služby zostanú aktuálne bez zbytočného zaťažovania každodennej práce redakcie technikou.