На сервере может происходить много разного: регистрации пользователей, новые комментарии, кто-то начал видеотрансляцию, поступили сигналы от датчиков, случились системные события и так далее. О некоторых таких событиях было бы здорово узнавать сразу, как они произошли. Если это наш собственный сервер, то всё просто: добавляем службу мониторинга и ждём, пока наступит нужное событие.
Но на внешних публичных серверах такое сделать не получится — доступ к скриптам нам никто не даст. Вместо этого владельцы серверов часто используют вебхуки.
Что такое вебхук
Вебхук — это технология оповещения о новых событиях на сервере. С английского webhook дословно переводится как «веб-крюк» — мы как бы цепляем крюк на сервер к какому-то событию, а когда оно наступает, то мы сразу узнаём об этом.
Новым событием может быть что угодно:
- регистрация нового пользователя,
- начало новой видеотрансляции,
- новый комментарий к записи,
- лайки, шеры и репосты,
- товар в корзине,
- новый товар на витрине,
- смена статуса по заявке.
Кроме самого события, сервер может передавать дополнительные данные: время события, логин пользователя, количество регистраций и другие параметры. Что именно передаёт сервер и в каком порядке — зависит от настроек сервера.
Чтобы сервер знал, куда отправлять данные, на странице делают специальное поле ввода адреса — туда мы вставляем адрес нашего сервера, который эти данные получит. Например, у конструктора страниц Тильда это сделано так: после выбора события, на которое нужно среагировать, мы попадаем на страницу, куда вводим адрес своего сервера, и выбираем, что ещё передавать:
Куда отправляются данные
Когда на сервере срабатывает вебхук, он отправляет данные на тот адрес, который мы сами указываем в настройках вебхука. Чтобы мы могли принять эти данные, по указанному адресу должен работать наш скрипт — он и будет обрабатывать входящие сообщения.
Получается, что в вебхуках участвуют два сервера: один отправляет данные, а второй принимает. Отправляет, соответственно, чужой; принимает — наш. Допустим, мы хотим сделать так, чтобы все данные, которые пришли в вебхуке, отправлялись нам на почту. Для этого создаём на сервере php-скрипт mail.php и кладём его, например, в папку myserver.ru/test
. В скрипте пишем такое:
<?php
header('Access-Control-Allow-Origin: *');
$headers = "From: webhookl@mihailmaximov.ru";
$message = print_r($_POST,true);
@mail('mail@mihailmaximov.ru', 'Новый вебхук!', $message, $headers);
echo"ok";
?>
Теперь мы можем указать адрес myserver.ru/test
как адрес для отправки вебхуков. Вот что произойдёт, когда на внешнем сервере сработает нужное событие:
- Внешний сервер обработает событие, сформирует данные и отправит их нам по адресу
myserver.ru/test
. - В этой папке у нас лежит скрипт mail.php, который сразу начнёт обрабатывать поступившие данные.
- После обработки скрипт отправит нам на mail@mihailmaximov.ru новое письмо. Оно будет отправлено с адреса webhookl@mihailmaximov.ru, а в теме письма будет написано «Новый вебхук!».
- Внутри письма будут все данные из вебхука — скрипт получит их с помощью переменной $message.
Это самый простой пример обработки вебхуков. Вместо отправки данных по почте можно заносить их в свою базу, выполнять новые скрипты, запускать связанные микросервисы, оповещать пользователей и делать что угодно ещё.
Как на сервере появляются вебхуки
Чтобы сервер мог работать с вебхуками, их нужно создать заранее:
- Разработчики серверного софта прикидывают, о чём пользователям было бы полезно узнавать сразу, как только это случилось, например комментарии и новые регистрации.
- Добавляют механизм оповещений в свои скрипты.
- На отдельной странице на сервере создают поле для ввода адреса, на который будут отправляться данные.
Это значит, что не у каждого сервиса в интернете есть вебхуки — только у тех, которые сделали их специально.
Чем вебхук отличается от API
Ключевая разница между ними в том, кто первый начинает что-то делать.
Если мы работаем с сервером по API, то мы должны сначала сделать запрос, узнать, есть ли новые события, и если есть — сделать новый запрос, чтобы их получить:
С вебхуками всё проще: сервер сам следит за событиями и первый отправляет нам новые данные:
Как это применяется в жизни
Представим, что мы сделали на «Тильде» страницу с формой регистрации на мероприятие. Когда регистрируется новый участник, данные о нём попадают во внутреннюю систему «Тильды» и, например, записываются в новую гуглотаблицу — на этом действия после регистрации заканчиваются.
Но мы хотим, чтобы каждый участник после регистрации получил приветственное письмо. Для этого мы создаём новый вебхук в «Тильде» и указываем адрес нашего сервера. По этому адресу мы размещаем скрипт, который возьмёт данные из поступившего вебхука, добавит их в шаблон письма и отошлёт новому участнику. Получается, что с помощью вебхуков можно автоматизировать разные события и создавать цепочки действий, привязанных к этому событию.
Работа с объёмными данными
Вебхук — инструмент оповещения, а не передачи объёмных данных. Если мы захотим передавать через вебхук сразу много информации, сервер может заблокировать такие вызовы и запретить отправку данных на наш адрес. Если с сервера всё-таки нужно забирать что-то большое, лучше использовать API в связке с вебхуками:
- Настраиваем вебхук на сервере на нужное нам событие.
- Как только оно срабатывает — нам приходит оповещение.
- В этот момент мы отправляем на сервер API-запрос, где просим отдать нам много данных.
- Сервер через API отдаёт нам всё, что нужно.
При таком подходе мы решаем сразу две проблемы: сразу узнаём, что на сервере что-то произошло, и получаем стабильный канал передачи данных.
Вебхуки — не самый надёжный способ оповещений
Вебхук — это просто разовый POST-запрос на наш сервер. Это значит, что если по каким-то причинам мы не успели обработать этот запрос, то данные будут потеряны. У вебхуков нет гарантированной доставки, поэтому привязывать к ним критичные события не стоит — лучше поискать другой механизм мониторинга.
Ещё бывает так, что проблемы могут быть на самом сервере. Например, если зависнет сервис, который рассылает вебхуки, то мы об этом не узнаем и не получим новых данных.
Что дальше
Теперь, когда мы знаем, как работают вебхуки, можем сделать свой обработчик вебхуков на сервере и поработать с вебхуками из внешних сервисов. Этим займёмся уже в следующий раз.