Шта је веб-хук и како га користите?

Веб-хукови омогућавају веб-базираним апликацијама да комуницирају коришћењем прилагођених повратних позива.

Коришћење веб-хукова омогућава веб апликацијама да аутоматски комуницирају са другим веб апликацијама.

За разлику од традиционалних система у којима један систем (субјект) стално прозива други систем (посматрача) за неке податке, веб-хукови омогућавају посматрачу да аутоматски убаци податке у систем субјекта кад год се догоди неки догађај.

Ово елиминише потребу за сталним праћењем од стране субјекта. Веб-хукови функционишу у потпуности на Интернету и стога се сва комуникација између система мора одвијати у облику ХТТП порука.

Коришћење веб-хукова

Веб-хукови се ослањају на присуство статичких УРЛ-ова који упућују на АПИ-је у систему субјекта који треба да буду обавештени када се догађај деси у систему посматрача. Пример овога би била веб апликација дизајнирана да прикупља и управља свим поруџбинама постављеним на Амазон налог корисника. У овом сценарију, Амазон делује као посматрач, а Вебапп за управљање прилагођеним поруџбинама делује као субјект.

Уместо да прилагођена веб-апликација периодично позива Амазон АПИ-је да би проверила да ли је направљена поруџбина, веб-хук креиран у прилагођеној веб-апликацији би омогућио Амазону да аутоматски пошаље наруџбу која је недавно креирана у веб-апликацији преко регистрованог УРЛ-а. Стога, да би се омогућило коришћење веб-хукова, субјект мора да има одређене УРЛ адресе које прихватају обавештења о догађајима од посматрача. Ово смањује значајно оптерећење на објекту пошто се ХТТП позиви упућују између две стране само када дође до неког догађаја.

Системи засновани на анкетирању наспрам система заснованих на вебхоок-у

Када посматрач позове веб-хук субјекта, субјект може да предузме одговарајућу акцију са овим новодостављеним подацима. Обично се веб-хукови обављају путем ПОСТ захтева за одређени УРЛ. ПОСТ захтеви вам омогућавају да пошаљете додатне информације објекту. Поред тога, може се користити и за идентификацију између бројних различитих могућих догађаја уместо за прављење засебних УРЛ-ова веб-хука за сваки догађај.

Вебхоок радни ток

Да бисте имплементирали улазне веб-хукове на своју апликацију, потребно је да извршите следеће основне кораке:

• Изложите АПИ крајњу тачку на серверу апликација која прихвата и обрађује ХТТП ПОСТ позиве
• Омогућите приступ овој крајњој тачки потенцијалним корисницима веб-хука. АПИ крајња тачка ће позвати апликацију извора података кад год се испуне релевантни услови.
• Обрадите ПОСТ податке и вратите одговор иницијатору позива веб-хука да бисте назначили статус. Овај корак може или не мора бити присутан.

Веб-хукови наспрам АПИ-ја

И веб-хукови и АПИ-ји имају за циљ успостављање комуникације између апликација. Међутим, постоје неке јасне предности и недостаци коришћења Вебхоокс-а у односу на АПИ-је за постизање интеграције апликације.

Веб-хукови обично буду боља решења ако су следеће тачке релевантније за имплементирани систем:

• Ако се подаци често ажурирају на серверу, веб-хукови обично буду боља решења јер се елиминишу непотребни АПИ позиви од клијента ка серверу. Према рестхоокс.цом, 98,5% АПИ анкета одлази у отпад.
• Вебхоокови омогућавају боља решења за системе који захтевају ажурирање података скоро у реалном времену. АПИ анкете се обично покрећу у одређеним интервалима који могу спречити ажурирање података уживо. Код веб-хук-ова, ажурирања се шаљу са сервера клијенту чим се покрене веб-хук.

У неким другим ситуацијама треба дати предност коришћењу АПИ-ја у односу на веб-хукове.

Ствари које треба размотрити

Важне ствари које треба узети у обзир при коришћењу АПИ-ја на Вебхоокс-у су:

• Коришћење АПИ-ја омогућава више прилагођавања када да се анкетирају подаци са сервера, као и колико података да се анкетира са сервера. Количина података за испитивање је регулисана величином АПИ анкете. Са веб-хуковима, сервер генерално одлучује о подацима и када се шаљу.
• За системе са веома променљивим подацима (као што су системи у реалном времену, ИоТ системи, итд.), анкетирање засновано на АПИ-ју може бити боља опција јер за сваки АПИ позив постоји велика вероватноћа употребљивих одговора.
• Могуће је да клијент потпуно игнорише податке који се шаљу са сервера, преко веб-хука, у случају да су РЕСТ крајње тачке ван мреже. У случају да сервер нема механизам за поновни покушај таквих неуспешних притисака, ажурирања података су потпуно изгубљена.

Да бисте се суочили са могућношћу губитка података послатих са сервера када веб-хук пређе ван мреже, можете да користите ред за размену порука о догађајима да архивирате те позиве. Примери платформи које пружају такву функционалност укључују РаббитМК o Амазонова једноставна услуга чекања (СКС). Оба су дизајнирана да делују као посредничка средства за складиштење порука која избегавају могућност пропуштања веб-хука позива.

Ercole Palmeri