Kio estas rethoko kaj kiel vi uzas ĝin?

Rethokoj permesas ret-bazitajn aplikojn interagi helpe de kutimaj revokoj.

Uzado de rethokoj permesas retprogramojn aŭtomate komuniki kun aliaj retprogramoj.

Male al tradiciaj sistemoj kie unu sistemo (subjekto) daŭre balotas alian sistemon (observanto) por kelkaj datenoj, rethokoj permesas al la observanto aŭtomate puŝi datenojn en la sistemon de la subjekto kiam ajn okazaĵo okazas.

Ĉi tio forigas la bezonon de konstanta monitorado de la subjekto. Webhooks funkcias tute en la Interreto kaj tial ĉiu komunikado inter sistemoj devas okazi en formo de HTTP-mesaĝoj.

Uzante rethokojn

Rethokoj fidas je la ĉeesto de senmovaj URL-oj montrantaj al APIoj en la sistemo de la subjekto, kiuj devas esti sciigitaj kiam okazaĵo okazas en la sistemo de la observanto. Ekzemplo de tio estus TTT-aplikaĵo dizajnita por kolekti kaj administri ĉiujn mendojn faritajn sur la Amazon-konto de uzanto. En ĉi tiu scenaro, Amazon funkcias kiel la observanto kaj la Custom Order Management Webapp funkcias kiel la subjekto.

Anstataŭ havi la laŭmendan retejon periode voki la Amazon-APIojn por kontroli por kreita mendo, rethoko kreita en la kutima retapp permesus al Amazon aŭtomate sendi mendon nove kreitan en la retprogramo per registrita URL. Tial, por ebligi la uzon de rethokoj, la subjekto devas havi indikitajn URL-ojn kiuj akceptas eventosciigojn de la observanto. Ĉi tio reduktas signifan ŝarĝon sur la objekto ĉar HTTP-vokoj estas faritaj inter la du partioj nur kiam okazaĵo okazas.

Sistemoj bazitaj en balotado kontraŭ sistemoj bazitaj en rethook

Post kiam la rethoko de la subjekto estas vokita de la observanto, la subjekto povas fari la taŭgan agon kun ĉi tiuj lastatempe senditaj datumoj. Tipe, rethokoj estas faritaj per POST-petoj al specifa URL. POST-petoj permesas sendi pliajn informojn al la objekto. Aldone, ĝi ankaŭ povas esti uzata por identigi inter kelkaj diversaj eblaj eventoj anstataŭ krei apartajn rethokajn URLojn por ĉiu evento.

Webhook laborfluo

Por efektivigi enirajn rethokojn sur via aplikaĵo, vi devas plenumi la jenajn bazajn paŝojn:

• Eksponu API-finpunkton sur via aplikaĵoservilo, kiu akceptas kaj prilaboras HTTP-POST-vokojn
• Provizu aliron al ĉi tiu finpunkto por eblaj rethook-uzantoj. La API-finpunkto vokos datumfontan aplikaĵon kiam ajn la koncernaj kondiĉoj estas plenumitaj.
• Prilaboru la POST-datumojn kaj resendu respondon al la rethook-voka iniciatinto por indiki la statuson. Ĉi tiu paŝo povas aŭ ne ĉeesti.

Webhooks kontraŭ APIoj

Kaj rethokoj kaj APIoj havas la celon establi komunikadon inter aplikoj. Tamen, estas iuj apartaj avantaĝoj kaj malavantaĝoj uzi Webhooks super API-oj por atingi aplikan integriĝon.

Rethokoj tendencas esti pli bonaj solvoj se la sekvaj punktoj pli rilatas al la efektivigita sistemo:

• Se la datumoj estas ofte ĝisdatigitaj sur la servilo, rethokoj tendencas esti pli bonaj solvoj ĉar nenecesaj API-vokoj de la kliento al la servilo estas eliminitaj. Laŭ resthooks.com, 98,5% de API-enketoj malŝpariĝas.
• Rethokoj ebligas pli bonajn solvojn por sistemoj, kiuj postulas preskaŭ realtempajn datumĝisdatigojn. API-enketoj tipe funkcias je fiksitaj intervaloj, kiuj povas malhelpi vivajn datumojn esti ĝisdatigitaj. Kun rethokoj, ĝisdatigoj estas senditaj de la servilo al la kliento tuj kiam la rethoko estas ekigita.

Uzado de la API devus esti preferita ol rethokoj en iuj aliaj situacioj.

Aferoj por konsideri

La gravaj aferoj por konsideri por uzi API-ojn sur Webhooks estas:

• Uzado de la API permesas pli da personigo de kiam baloti por datumoj de servilo kaj ankaŭ kiom da datumoj baloti de la servilo. La kvanto de datumoj balotendaj estas regata de la API-enketgrandeco. Kun rethokoj, la servilo ĝenerale decidas la datumojn kaj kiam ĝi estas sendita.
• Por sistemoj kun tre variaj datumoj (kiel realtempaj sistemoj, IoT-sistemoj, ktp.), API-bazita balotado povus esti pli bona elekto ĉar por ĉiu API-voko, ekzistas alta probableco de uzeblaj respondoj.
• Eblas ke datumoj senditaj de servilo, per rethoko, estu tute ignoritaj de la kliento, se la REST-finpunktoj estas eksterrete. Se la servilo ne havas mekanismon por reprovi tiajn malsukcesajn puŝojn, datumaj ĝisdatigoj estas tute perditaj.

Por trakti la eblecon perdi datumojn senditajn de servilo kiam la rethoko malkonektas, vi povas uzi eventon mesaĝvicon por arkivi tiujn vokojn. Ekzemploj de platformoj kiuj disponigas tian funkciecon inkluzivas KunikloMQ o Simpla Queue Service (SQS) de Amazon. Ambaŭ estas dizajnitaj por funkcii kiel peraj mesaĝaj stokejoj, kiuj evitas la eblecon maltrafi rethookvokon.

Ercole Palmeri