Rozdíl spočívá především v čase
Redakce v 10:14 zveřejní změnu kontaktní poradny. Web musí ihned ukázat nové telefonní číslo, vyhledávání na vlastním portálu má obnovit index a srozumitelná jazyková verze později potřebuje odbornou kontrolu. Tyto následky patří k jedné změně, ale nemusejí se zpracovat ve stejném okamžiku.
Webhook je zpráva, kterou systém odešle jinému systému bezprostředně po události. Redakční systém například oznámí: „Tato stránka byla zveřejněna.“ Přijímající systém pak může stáhnout a zpracovat právě tento obsah. Nečeká na další obecný běh ani se neustále nedotazuje na změny.
Při dávkovém zpracování se několik úkolů shromáždí a provede společně. Každý večer lze například zkontrolovat všechny stránky změněné během dne a vytvořit zprávu. Běh není okamžitý, ale lze jej dobře plánovat. Zpracuje velké množství položek postupně a poskytne souvislý přehled výsledku. Má známý začátek a rozpoznatelný konec.
Webhooky se hodí pro jednotlivé důležité události
Webhooky dávají smysl, pokud rychlá reakce přináší jasný užitek. Po zveřejnění varování má aplikace dostat stejný aktuální obsah. Po stažení stránky má zmizet z interního hledání. Zprávu pokaždé vyvolává konkrétní činnost a týká se jednoznačně určitelného obsahu.
Pro redakci působí postup okamžitě. Schválí příspěvek a krátce nato vidí novou verzi v připojeném kanálu. Rychlost však není zaručená současnost. Síťová chyba, údržba nebo přetížená protistrana mohou zpracování zpozdit. Systém musí taková přerušení zvládat.
Webhook nemá spouštět každé uložení. Automaticky uložený koncept ještě není důležitý pro veřejné hledání. Smysluplné události vycházejí z viditelného významu: zveřejněno, podstatně aktualizováno, staženo nebo odstraněno. Připojené systémy tak dostávají méně zpráv a jednoznačněji řeší důležité změny stavu. Interní opravu překlepu lze podle potřeby zpracovat jinak než nový fakt.
Dávkové zpracování odpovídá velkému množství a pevným termínům
Větší běh je vhodný pro mnoho položek zpracovávaných podle stejných pravidel. Organizace může chtít každou noc kontrolovat všechny zveřejněné stránky, zda nechybí datum kontroly. Pro čtenáře málo záleží na tom, zda je výsledek hotový ve 2:00, nebo 2:20. Okamžitá zpráva po každé malé úpravě by byla zbytečně náročná.
Také úplné nové sestavení může vědomě proběhnout souhrnně. Po změně vyhledávacího systému může být nutné znovu načíst 80 000 stránek. Jednotlivé webhooky zásobu spolehlivě nepopíší, protože změna se týká i nezměněného obsahu. Dávkový běh začíná se známým množstvím a dokumentuje úspěšně zpracované stránky.
Pevný čas usnadňuje plánování zátěže. Popisy obrázků, návrhy překladů nebo rozsáhlé kontroly kvality vyžadují výpočetní výkon a externí služby. Noční běh může tuto práci omezit, aniž zpomalí zveřejnění v redakčním systému. Jeho délka je předvídatelnější pro provoz i poskytovatele. Naléhavý obsah však potřebuje rychlejší cestu, pokud by čekání vedlo k nesprávným informacím.
Nejprve rozhoduje povolené zpoždění
Nejdůležitější otázka zní: Jak dlouho smí připojený systém ukazovat starý stav? U výstrahy před počasím mohou rozhodovat minuty. U měsíčního hodnocení kvality textu bývá den bez problému. Jasný časový údaj pomůže více než obecný požadavek na co nejrychlejší zpracování.
Poté záleží na rozsahu typické změny. Pokud se většinou zveřejní jedna stránka, webhook ji může přesně určit. Když se pravidelně mění celé soubory, je plánovaný běh přehlednější. Import 4 000 nových míst nemá nekontrolovaně spustit 4 000 souběžných následných úkolů.
Do rozhodnutí patří i následky výpadku. Ztracená zpráva může nechat v aplikaci zastaralé číslo. Neúspěšnou noční zprávu může redakce ráno spustit znovu. Přijatelné zpoždění má být výslovně sjednáno pro každý kanál. Čím větší okamžitá škoda, tím důležitější jsou rychlá opakování, viditelná varování a dodatečné porovnání celého souboru.
Zpráva webhooku zůstává malá a jednoznačná
Dobrá zpráva uvádí událost, dotčený obsah a čas vzniku. Přidává jednoznačné číslo události a verzi formátu zprávy. Přijímající systém si pak stáhne úplná aktuální data přes chráněné rozhraní. Zpráva zůstane přehledná a zbytečně neobsahuje celý článek.
Postup také brání tomu, aby opožděná zpráva rozšířila starý text. Redakce například dvakrát rychle opraví stejné číslo. První zpráva kvůli poruše přijde později než druhá. Pokud protistrana stáhne aktuální stav, dostane poslední schválenou verzi, ne obsah opožděné zprávy.
Osobní nebo důvěrný obsah do zprávy bez potřeby nepatří. Protokoly, chybová hlášení a administrativní rozhraní často ukládají data webhooku déle. V mnoha případech stačí identifikátor obsahu a druh události. Oprávněná protistrana stáhne další údaje, až když je skutečně potřebuje zpracovat. Tak i technické chybové hlášení zůstane bez zbytečného odborného obsahu.
Opakované zprávy jsou běžný případ
Pokud přijímající strana nepotvrdí přijetí zprávy, zdrojový systém ji odešle znovu. První zpráva už mohla být zpracována, ale její potvrzení se ztratilo. Protistrana proto musí stejnou událost přijmout vícekrát bez dvojího zveřejnění příspěvku nebo dvojí objednávky překladu.
Pomáhá jednoznačné číslo události. Pokud už bylo úspěšně zpracováno, systém opakování potvrdí a přeskočí. Je to spolehlivější než porovnávání časů nebo názvů. Dvě různé změny mohou nastat téměř současně a název se může změnit, přestože stále jde o tentýž obsah.
Ani pořadí není vždy jisté. Oznámení zveřejnění může přijít až po zprávě o pozdější opravě. Čísla verzí nebo stažení aktuálního obsahu zabrání vítězství staršího stavu. Pro redakce rozhoduje správný viditelný stav i při neklidné cestě technických zpráv. Samotný čas přijetí proto nesmí určovat platnou verzi.
Příjemce musí ověřit původ
Veřejně dostupnou adresu webhooku může oslovit i neoprávněný člověk. Protistrana proto nesmí zprávě důvěřovat jen proto, že přišla na očekávanou cestu. Běžná je digitální signatura vypočtená z obsahu a sdíleného tajného klíče. Příjemce ji znovu vypočítá a hodnoty porovná.
Přenos probíhá přes HTTPS, aby byly cestou chráněny obsah a přístupové údaje. Tajný klíč nepatří do zdrojového kódu, veřejné dokumentace ani textu zprávy. Uchovává se chráněně, je dostupný jen potřebným službám a pravidelně se mění. Staré klíče musejí po kontrolovaném přechodu přestat platit.
Časová značka navíc omezuje dobu přijatelnosti správně podepsané zprávy. Zaznamenaný požadavek tak nelze libovolně později zopakovat. Chybové odpovědi nemají útočníkům odhalovat interní podrobnosti. Vlastní tým přesto dostane dost údajů k cílenému zkoumání odmítnuté signatury nebo starého formátu. Podezřelé přístupy se omezují a srozumitelně protokolují pro bezpečnostní kontrolu s přiměřenými zdokumentovanými dobami uchování.
Velký běh potřebuje dohledatelný stav
U 20 000 stránek je dávkový běh málokdy úplně úspěšný nebo neúspěšný. Některý obsah může mít neplatné údaje, zatímco ostatní se zpracuje správně. Běh proto má pro každou položku zaznamenat úspěch a potřebu opakování. Jediná chybná stránka nesmí blokovat všechny následující.
Je nutné zohlednit limity externích služeb. Rozhraní může povolit jen určitý počet požadavků za minutu. Běh pak rozdělí množství do přijatelných částí a po přestávce pokračuje. Ukládá průběh, aby po restartu nezačal znovu první stránkou a zbytečně neopakoval již zaplacenou práci.
Pro redakci je srozumitelný výsledek důležitější než dlouhý technický protokol. Musí poznat dotčený běh, počet hotových položek a stránky vyžadující odbornou pomoc. Zpráva „37 chyb“ nestačí. Přiřazení k názvu stránky, adrese a konkrétnímu důvodu mění chybu v řešitelný úkol. Úspěšná opakování následně z otevřeného redakčního pohledu zmizí.
Plánovaný běh často doplňuje webhooky
Webhooky a dávkové zpracování se nevylučují. Zpravodajský portál může nové články ihned oznámit vyhledávání a v noci porovnat celý soubor. Rychlá cesta udržuje důležité změny aktuální. Plánovaný běh najde události chybějící kvůli poruše, nesprávnému nastavení nebo dočasně vypnuté protistraně.
Také srozumitelná jazyková verze může potřebovat oba časy. Změna odborné stránky pomocí webhooku ihned vytvoří úkol pro příslušnou redakci. Ověřená verze se automaticky nenahradí. Denní zpráva navíc ukáže všechny otevřené úkoly, jejich lhůty a obsah bez vazby na zdrojovou stránku.
Rozhodující je jasný zdroj platného stavu. Webhook oznamuje změnu a pravidelné porovnání potvrzuje aktuální soubor. Pokud přinášejí odlišné údaje, nesmí náhodou rozhodnout později spuštěný proces. Směrodatný zůstává publikační systém a připojené systémy s ním svůj stav srovnávají. Toto pravidlo musí zůstat jasně zdokumentované i po změně systému.
Provoz musí zůstat srozumitelný lidem
Technická spolehlivost se projevuje ve viditelných informacích. Týmy mají znát běžnou dobu přenosu a okamžik, od kterého se hlásí zpoždění. Varování uvádí dotčený kanál a obsah, ne jen interní název procesu. Redakce pak dokáže posoudit, zda návštěvníci právě vidí zastaralý stav.
Každý postup potřebuje odpovědné místo. Dokáže znovu odeslat uvízlou zprávu, pokračovat v dávkovém běhu nebo zastavit nesprávné zveřejnění. Zároveň musí být jasné, kdy je nutná odborná odpovědnost. Technický tým dokáže přenést soubor, ale nemůže rozhodnout, zda byla změněná podmínka nároku správně vysvětlena.
Vhodné řešení tedy vychází z obsahu, času a možné škody. Webhooky rychle reagují na jednotlivé události. Dávkové běhy zpracovávají plánovatelná množství a porovnávají soubory. Společně pokrývají aktuální změny i úplnost. Pokud se od začátku počítá s opakováním, bezpečností a srozumitelnými hlášeními, zůstávají připojené weby a služby aktuální bez zbytečné technické zátěže redakce.