Razlika leži prvenstveno u vremenu.
Redakcija objavljuje ažurirane kontakt podatke savjetovališta u 10:14 sati. Web stranica mora odmah prikazati novi telefonski broj, tražilica unutar portala mora ažurirati svoj indeks, a jasna i koncizna verzija kasnije će zahtijevati stručni pregled. Ove posljedice proizlaze iz iste promjene, ali ne moraju se sve rješavati istovremeno.
Webhook je poruka koju jedan sustav šalje drugome odmah nakon događaja. Na primjer, sustav za upravljanje sadržajem može izvijestiti: "Ova je stranica objavljena." Prijemni sustav tada može dohvatiti i urediti upravo taj sadržaj. Ne čeka sljedeće opće pokretanje niti stalno provjerava nove promjene.
Grupna obrada uključuje prikupljanje i izvršavanje više zadataka zajedno. Na primjer, svake večeri, sve stranice izmijenjene tog dana mogu se provjeriti za izvješće. Takav proces nije trenutan, ali se lako planira. Može sekvencijalno obraditi velike količine i pružiti rezultat kao kohezivan pregled. Obrada slijedi poznati početak i definirani kraj.
Webhookovi su prikladni za određene važne događaje.
Webhookovi su korisni kada pravovremeni odgovor nudi jasnu korist. Nakon što se objavi poruka upozorenja, aplikacija bi trebala dobiti isti ažurirani sadržaj. Nakon što se stranica povuče, trebala bi nestati iz internih rezultata pretraživanja. Svaku poruku pokreće određena radnja i odnosi se na jasno definirani sadržaj.
Uredničkom timu ovaj se proces čini trenutnim. Odobre doprinos i ubrzo vide novu verziju na povezanom kanalu. Međutim, ovu brzinu ne treba miješati sa zajamčenom simultanošću. Mrežne pogreške, održavanje ili zauzeti udaljeni poslužitelj mogu odgoditi obradu. Sustav mora biti u stanju podnijeti takve prekide.
Ne bi svaka spremljena promjena trebala pokrenuti webhook. Automatski spremljeni nacrt još nije relevantan za javno pretraživanje. Značajni događaji temelje se na njihovom vidljivom značaju: objavljeni, značajno ažurirani, povučeni ili izbrisani. To smanjuje broj obavijesti koje povezani sustavi primaju i omogućuje im jasnije rukovanje važnim promjenama stanja. Interne ispravke tipografskih pogrešaka mogu se po potrebi obraditi drugačije od novih informacija.
Serijska obrada je prikladna za velike količine i fiksne rokove.
Dulje izvođenje je prikladno kada se velika količina sadržaja obrađuje prema istim pravilima. Organizacija bi mogla htjeti svake večeri provjeravati sve objavljene stranice za nedostajuće datume pregleda. Je li rezultat dostupan u 2:00 ili 2:20 ujutro, čitateljima malo znači. Slanje trenutne obavijesti nakon svake manje izmjene bilo bi nepotrebno dugotrajno.
Potpuna ponovna izgradnja može se namjerno izvršiti u serijama. Nakon promjene sustava pretraživanja, možda će trebati ponovno skenirati 80 000 stranica. Pojedinačni webhookovi ne bi pouzdano predstavljali cijeli inventar jer bi to utjecalo i na nepromijenjeni sadržaj. Grupna ponovna izgradnja započinje poznatim brojem stranica i dokumenata koje su stranice uspješno obrađene.
Fiksni vremenski interval olakšava planiranje učitavanja. Opisi slika, nacrti prijevoda i opsežne provjere kvalitete zahtijevaju vrijeme obrade i vanjske usluge. Izrada preko noći može ograničiti ovo opterećenje bez usporavanja objavljivanja u uredničkom sustavu. Njegovo trajanje postaje predvidljivije i za tvrtku i za pružatelje usluga. Međutim, hitan sadržaj i dalje zahtijeva brži put ako bi dulje čekanje dovelo do netočnih informacija.
Dopušteno kašnjenje je prvi faktor koji treba uzeti u obzir.
Najvažnije pitanje je: Koliko dugo povezani sustav može prikazivati zastarjelu verziju? U slučaju upozorenja na loše vrijeme, minute mogu biti ključne. Za mjesečnu analizu kvalitete teksta, jedan dan obično nije problematičan. Jasna vremenska specifikacija je korisnija od općeg zahtjeva da sva obrada mora biti što brža.
Sljedeći faktor koji treba uzeti u obzir je opseg tipične promjene. Ako se obično objavljuje samo jedna stranica, webhook može odrediti tu točno stranicu. Ako se cijele baze podataka redovito mijenjaju, zakazano pokretanje je lakše upravljivo. Uvoz novih web-mjesta s 4000 unosa ne bi trebao nekontrolirano pokretati 4000 istovremenih zadataka praćenja.
Također se moraju uzeti u obzir posljedice prekida. Ako se poruka izgubi, u aplikaciji može ostati zastarjeli telefonski broj. Ako noćno izvješće ne uspije, redakcija ga može ponovno pokrenuti ujutro. Prihvatljivo kašnjenje treba biti izričito dogovoreno za svaki povezani kanal. Što je veća neposredna šteta, to su važnije brze snimke, vidljiva upozorenja i dodatna provjera cijele baze podataka.
Poruka webhooka ostaje mala i nedvosmislena.
Dobra vijest navodi što se dogodilo, na koji se sadržaj odnosi i kada se događaj dogodio. Također uključuje jedinstveni broj događaja i verziju formata poruke. Prijemni sustav zatim može dohvatiti potpune, ažurirane podatke putem sigurnog sučelja. To poruku čini sažetom i izbjegava nepotrebno uključivanje cijelog članka.
Ovaj postupak također sprječava da odgođena poruka distribuira zastarjeli tekst. Na primjer, pretpostavimo da urednički tim ispravlja isti telefonski broj dva puta zaredom. Prva poruka stiže kasnije od druge zbog tehničkog kvara. Ako odjel za prijem provjerava najnoviju verziju, i dalje će primiti najnoviju odobrenu verziju, a ne sadržaj odgođene poruke.
Osobne ili povjerljive informacije ne smiju se uključivati u poruku osim ako nije apsolutno neophodno. Zapisnici, izvješća o pogreškama i administratorska sučelja često pohranjuju podatke webhook-a dulje vrijeme. U mnogim slučajevima dovoljni su identifikator sadržaja i vrsta događaja. Ovlašteni primatelj dohvaća daljnje informacije samo kada ih stvarno treba obraditi. To osigurava da čak i izvješće o tehničkoj pogrešci ostane bez nepotrebnih tehničkih detalja.
Ponavljane poruke su normalna pojava.
Ako prijemni sustav ne potvrdi primitak poruke, pošiljatelj je ponovno šalje. Možda je prva poruka već obrađena, ali je njezina potvrda izgubljena. Stoga prijemni sustav mora biti u mogućnosti prihvatiti isti događaj više puta bez dvostrukog objavljivanja posta ili dvostrukog naručivanja istog prijevoda.
Jedinstveni broj događaja pomaže u tome. Ako je ovaj broj već uspješno obrađen, sustav može potvrditi ponavljanje i preskočiti ga. To je pouzdanije od usporedbe vremena ili naslova. Dvije različite promjene mogu se dogoditi gotovo istovremeno, a naslov se može promijeniti iako sadržaj ostaje isti.
Redoslijed objava također nije uvijek pouzdan. Obavijest o objavi može stići nakon obavijesti o kasnijoj ispravci. Brojevi verzija ili trenutni datum pristupa sadržaju sprječavaju da starija verzija ima prednost. Za uredničke timove to znači: Vidljiva verzija mora biti ispravna, čak i ako tehničke poruke krenu nepredvidivim putem. Stoga sam datum primitka ne bi trebao određivati valjanu verziju.
Primatelj mora provjeriti podrijetlo.
Javno dostupnoj webhook adresi u načelu mogu pristupiti i neovlaštene strane. Primatelj stoga ne bi trebao vjerovati poruci samo zato što stiže na očekivani put. Digitalni potpis, izračunat iz sadržaja i zajedničkog tajnog ključa, standardna je praksa. Primatelj ga ponovno izračunava i uspoređuje dvije vrijednosti.
Prijenos se odvija putem HTTPS-a kako bi se zaštitio sadržaj i pristupni podaci tijekom prijenosa. Tajni ključ nije uključen u izvorni kod, javnu dokumentaciju ili tijelo poruke. Sigurno se pohranjuje, dostupan je samo potrebnim uslugama i redovito se obnavlja. Stari ključevi moraju se poništiti nakon kontroliranog prijenosa.
Vremenska oznaka dodatno ograničava koliko dugo se ispravno potpisana poruka prihvaća. To sprječava da se snimljeni zahtjev kasnije proizvoljno ponavlja. Odgovori na pogreške ne bi smjeli otkrivati nikakve interne detalje napadačima. Međutim, zadržava se dovoljno informacija da tim posebno istraži odbijeni potpis ili zastarjeli format poruke. Sumnjivi pokušaji pristupa ograničeni su i bilježe se na način koji se može pratiti za sigurnosne revizije. Primjenjuju se odgovarajuća i jasno dokumentirana razdoblja čuvanja.
Za odličan trk potrebna je razumljiva početna točka.
S 20.000 stranica, ispis rijetko bude potpuni uspjeh ili potpuni neuspjeh. Neki sadržaji mogu sadržavati nevažeće informacije, dok se ostatak obrađuje ispravno. Stoga bi ispis trebao zabilježiti za svaki unos što je bilo uspješno, a što treba ponoviti. Jedna neispravna stranica ne bi trebala blokirati sve sljedeće stranice.
Moraju se uzeti u obzir ograničenja vanjskih usluga. Sučelje može dopustiti samo određeni broj zahtjeva u minuti. Proces zatim dijeli volumen na upravljive dijelove i nastavlja nakon pauze. Sprema svoj napredak tako da ponovno pokretanje ne počinje ponovno na prvoj stranici i nepotrebno ne ponavlja posao koji je već plaćen.
Za urednički tim, jasan i razumljiv rezultat je važniji od dugačke tehničke datoteke zapisnika. Moraju moći vidjeti koji je ispis pogođen, koliko je sadržaja dovršeno i koje stranice zahtijevaju tehničku pomoć. Poruka poput "37 grešaka" nije dovoljna. Povezivanje greške s naslovom stranice, adresom i konkretnim razlogom pretvara je u upravljiv zadatak. Uspješna ponavljanja tada nestaju iz javnog uredničkog pogleda.
Često planirano pokretanje nadopunjuje webhookove.
Webhookovi i skupna obrada nisu međusobno isključivi. Portal vijesti može odmah prijaviti nove članke svojoj funkciji pretraživanja i sinkronizirati cijelu arhivu preko noći. Ovaj brzi pristup održava važne promjene ažurnima. Planirana obrada pronalazi događaje koji nedostaju zbog kvara, neispravne postavke ili privremeno izvan mreže poslužitelja.
Jasna i koncizna verzija može zahtijevati oba puta. Ako se promijeni predmetna stranica, webhook odmah generira zadatak za odgovorni urednički tim. Pregledana verzija se ne zamjenjuje automatski. Dnevno izvješće dodatno prikazuje sve otvorene zadatke, njihove rokove i sadržaj tamo gdje nedostaje poveznica na izvornu stranicu.
Jasan izvor za valjano stanje je ključan. Webhook prijavljuje promjenu, a redovita sinkronizacija potvrđuje trenutni status. Ako oba pružaju različite informacije, najnovije izvršeni proces ne smije proizvoljno prevladati. Sustav objavljivanja ostaje autoritativan, a povezani sustavi sinkroniziraju svoje stanje s njim. Ovo pravilo mora ostati jasno dokumentirano čak i nakon promjene sustava.
Radnja mora ostati razumljiva ljudima.
Tehnička pouzdanost demonstrira se vidljivim informacijama. Timovi bi trebali znati koliko obično traje prijenos i kada se prijavljuje kašnjenje. Upozorenje navodi pogođeni kanal i sadržaj, a ne samo interni naziv procesa. To omogućuje uredničkom timu da procijeni gledaju li posjetitelji trenutno zastarjelu verziju.
Svaki proces zahtijeva odgovornu stranu. Ta strana može ponovno poslati zaglavljenu poruku, nastaviti skupni proces ili zaustaviti netočnu objavu. Istovremeno, mora biti jasno kada je potrebna profesionalna odgovornost. Tehnički tim može prenijeti datoteku, ali ne može odlučiti je li promijenjeni uvjet zahtjeva ispravno objašnjen.
Odgovarajuće rješenje stoga proizlazi iz sadržaja, vremena i potencijalne štete. Webhookovi brzo reagiraju na pojedinačne događaje. Serijska izvođenja obrađuju predvidljive količine i usklađuju inventure. Zajedno pokrivaju trenutne promjene i osiguravaju potpunost inventara. Ako se od samog početka uzmu u obzir ponavljanja, sigurnost i jasne obavijesti, povezane web stranice i usluge ostaju ažurne bez opterećenja svakodnevnog rada uredničkog tima nepotrebnom tehnologijom.