url webhook что это

Вебхук

Вебхук — это способ оповещения клиента о произошедшем в системе событии с помощью пользовательских обратных вызовов по HTTP.

Это термин из мира WEBа и программирования. Вебхук запускается, когда на вашем сайте, в CRM, чат-боте или иной системе происходит какое-то событие. Например, человек написал комментарий или в товароучетную систему добавили новый товар. Когда происходит такое событие, сервер создает HTTP-вызов и отправляет его на адрес, указанный клиентом для получения вебхуков. Клиент вовремя получает свежие данные — клиент доволен.

Пользователь может настроить веб-хук так, чтобы события на одних сайтах вызывали действия на другом. Например, человек создает в интернет-магазине заказ → система отправляет вебхук в приложение владельца → приложение уведомляет владельца и отправляет человеку смету.

Зачем нужен вебхук, если есть API

Большинство API работает по принципу «Спроси меня и я отвечу». То есть для получения свежих данных, программному клиенту нужно постоянно отправлять запросы на сервер. Вебхуки работают иначе. Они как бы говорят: «Дружище, больше не нужно названивать. Если произойдет что-то для тебя важное, я сам сообщу». Схема запроса обратной связи по API. Программный клиент регулярно опрашивает сервер о наличии изменений. Если их нет, сервер дает отрицательный ответ. Если есть — оповещает об изменениях

Если простыми словами, вебхук — как бы подписка на обновления для определенных событий. Сервер будет оповещать клиента только о тех изменениях, которые ему по-настоящему важны. Он сам сообщит об этих событиях при настройке вебхука.

Это упрощает процесс обмена данными и для программного клиента, и для провайдера. Не забываем, что вебхук — это обратный вызов по HTTP. При настройке не потребуется громоздкая инфраструктура из кода. Схема передачи данных в случае применения вебхука. Сервер сам оповещает клиента, если появится интересующая его информация. Постоянно отправлять запросы не нужно

Обычно вебхук запрашивает данные у сервера в форме POST-запроса, а программный клиент интерпретирует его самостоятельно. Для этого на клиентской стороне строится интерфейс взаимодействия с POST-запросом. Пользователь самостоятельно определяет случаи, при которых сервер должен оповестить об изменениях, вебхук захватывает данные и передает клиенту, а тот их идентифицирует и интерпретирует.

Когда применяется API, адреса для запроса данных формируются и предоставляются клиенту самим сервером. Программный клиент вызывает эти адреса и получает интересующие его изменения. Или не получает, если их нет. Пример запросов к API от клиентского приложения. Клиент запрашивает данные о созданных и прочитанных сообщениях и комментариях

Вебхук работает в обратном порядке: URLы для отправки запроса формируется клиентом. А сервер, если на его стороне происходит важное для пользователя событие, использует эти URLы для отправки оповещения программному клиенту.

Представим, что пользователь хочет получать уведомления всякий раз, когда на его площадке появляется новое сообщение. Он создает необходимый интерфейс и настраивает вебхуки. Затем:

Как выглядит вебхук

По сути, вебхук — это программный код. Обычно он состоит из двух частей — переменной и самих данных. Например, как здесь. «First name» — это переменная, а «Anton» — это данные, которые передаются с помощью вебхука, которые постоянно меняются и подставляются системой. Количество переменных определяется софтом, на события в котором реагирует вебхук

Предпринимателю, маркетологу и другому обывателю не нужно понимать, а тем более составлять код. Почти всегда система сама составляет код и отправляет его в виде запроса на указанный клиентом адрес. А там этот код отображается уже в графическом интерфейсе в виде набора данных.

Как используют вебхуки на практике

Сегодня вебхуки используются повсеместно. Вот несколько примеров на скорую руку:

Чтобы упростить работу с вебхуками, поставщики данных предоставляют пользователям готовые интерфейсные панели. На них можно создать новый вебхук, указать URL, на который будет отправлен вызов, выбрать событие и передаваемые параметры. Пользователю не нужно возиться с кодом — он заполняет простую форму, а за программную часть работы отвечает поставщик данных. Панель для создания и управления вебхуками от сервиса Callibri. Пользователь указывает адрес для отправки запроса, задает событие и его параметры. А все остальное делает сам сервис

Создаем тестовый вебхук

Кажется, что работать с вебхуками, при наличии программной панели от поставщика данных, просто. Перейдем от теории к практике — посмотрим, как это работает на примере.

Чтобы создать тестовый вебхук, не нужен свой сайт или приложение. Проверить работоспособность входящего запроса можно с помощью специального сервиса — Webhook.site. Он генерирует для вас тестовый урл, который можно использовать для отправки POST-запроса и проверки его содержимого на этом же сайте. Показываем, как это работает. Для проверки будем использовать свой репозиторий на Github.

Если вы пользуетесь сервисом, который дает возможность отправлять уведомления с помощью вебхуков, протестируйте его похожим образом. Например, если используете Dropbox, можно протестировать отправку уведомлений для события «внесение изменения в файл».

Помощь в отладке вебхуков

Вебхуки являются ассинхронной моделью программирования, поэтому их ручная отладка часто вызывает сложности. Мы поговорили с нашим отделом разработки и они рассказали нам про несколько сервисов, которые сильно упрощают процесс отладки. Если вы программируете и отлаживаете вебхуки самостоятельно или планируете это делать, вам будет полезно знать про:

Читайте также: uwamson aml что это

Безопасно ли пользоваться вебхуками

Обычно механизм использования вебхуков предусматривает доставку данных программному клиенту через публичные адреса URL. Это небезопасно: любой может перехватить эти адреса и подменить передаваемые данные в своих корыстных целях. Но этого можно избежать. Есть несколько способов:

О чем нужно помнить, если используешь вебхуки

Возможна потеря данных. Бывает, что доставив запрос с данными программному клиенту, вебхук перестает отвечать. Обычно это связано с ошибкой на стороне сервиса. С чем бы это ни было связано, из-за такой ошибки всегд аесть риск потерять данные. Поэтому мы советуем заранее готовиться к тому, что приложение или сайт могут упасть. Узнайте заранее, как поставщик данных обрабатывает ответы и создает ли он резервные копии на случай, если сервис ляжет.

Приложение может не выдержать нагрузку. В зависимости от вида вашей деятельности и настроенных триггеров, события на стороне сервера могут происходить слишком часто. Чем больше триггеров для отправки вебхука вы задаете, тем чаще программный клиент будет получать POST-запросы. Убедитесь, что ваше приложение готово к получению запрашиваемого объема данных. Если на сервере возникнет высокая активность, клиентское приложение может не выдержать нагрузки. Так бывает, например, при DDoS-атаках.

Не стоит передавать через вебхуки данные. Технически технология вебхук позволяет передавать программному клиенту объемные массивы данных. Но делать этого не стоит. Используйте вебхуки лишь для уведомления об изменении состояния на сервере. А когда сигнал получен — вызывайте API,запрашивайте данные и получайте настоящую нагрузку. Такой способ позволяет надежнее обрабатывать данные и не перегружать систему.

Источник

Вебхуки: как получать данные без промедления и опросов API

Leo Matyushkin

В сфере веб-разработки наряду с API распространилось понятие вебхук (англ. webhook). Рост популярности этого стандарта связан с тем, что всё больше действий в вебе можно описать в терминах событий. Триггерами, запускающими вебхук, могут служить, например, отправка кода в репозиторий или публикация комментария.

Вебхук – это механизм оповещения о происходящих в системе событиях посредством функций обратных вызовов. Когда случается интересующее клиента событие, сервер отправляет HTTP-запрос на URL-адрес, предоставленный клиентом для приема вебхуков.

Чем вебхуки отличаются от API?

В типичных API для получения информации от сервера его необходимо постоянно опрашивать. В случае вебхуков сервер как бы говорит клиенту: «Теперь тебе не придется названивать. Я сам позвоню, когда появится что-то новое».

То есть с помощью вебхука клиент «подписывается» на получение оповещений в заранее определенных случаях. Такой подход удобнее и для провайдера информации, и для клиента. При этом вебхуки используют HTTP, то есть не требуется добавления какой-то дополнительной инфраструктуры.

Вебхук делает HTTP-запрос к вашему приложению (чаще всего POST-запрос в JSON-формате), а интерпретация запроса уже зависит от принимающей стороны. Вебхуки — это своеобразные «обратные API» – интерфейс взаимодействия с запросом должен быть построен на стороне клиента.

У большинства API необходимо вначале отправить запрос, за которым последует ответ системы. В случае вебхука вы заранее настраиваете, при каких событиях сервер отправляет данные. Рассмотрим на примере.

В случае API приложение сервера предоставляет приложению клиента адреса, которые может вызывать приложение на стороне клиента. Например, для доски сообщений запросы к API могут выглядеть следующим образом:

Для вебхуков ситуация обратная: уже приложение клиента предоставляет приложению сервера адреса для вызова. А приложение сервера в свою очередь использует эти URL, когда на стороне сервера происходит какое-либо интересующее клиента событие.

Допустим, мы хотим, чтобы сервер уведомлял приложение клиента при добавлении нового комментария. Всякий раз, когда новый комментарий публикуется в базе данных на стороне сервера, приложение сервера должно (после публикации комментария в базе данных) вызывать URL вебхука, чтобы клиент знал, что доступен новый комментарий.

Примеры использования вебхуков

Оглянувшись вокруг, мы увидим, что многие компании внедрили вебхуки в своей практике. Несколько примеров:

Поставщики данных могут предоставлять специальные панели для удобства указания ссылок, куда отправляются HTTP-запросы. Ниже представлена панель управления вебхуками сервиса Intercom.

Попробуйте свои силы

Лучший способ понять технологию применения вебхуков — это попробовать ее в деле. Давайте поэтапно рассмотрим процесс настройки и получения вебхука на реальном примере.

Даже если у вас нет приложения и соответствующих URL, можно попробовать технологию вебхуков в деле. Для таких задач создан ресурс webhook.site. Он генерирует уникальную ссылку для проверки входящих POST-запросов.

Скопируем сгенерированную ссылку, и, оставив страницу открытой, передадим URL провайдеру вебхука. Например, настроим вышеупомянутый вебхук в GitHub. Для этого перейдем в каком-либо из своих репозиториев в раздел Settings/Webhooks и нажмем кнопку Add webhook.

Заполнение открывшейся формы является процессом настройки вебхука. В поле Payload URL вставим запасенную ссылку с webhook.site. В качестве Content type выберем application/json. Далее отметим события, при которых GitHub будет отправлять запрос, например, комментарий коммита.

В конце списка нажимаем кнопку активации вебхука. Оставляем в репозитории комментарий к коммиту, чтобы протестировать механизм.

При этом GitHub в соответствии с вебхуком сразу же отправит POST-запрос на нашу ссылку. Вернувшись на страницу webhook.site, увидим, что в списке запросов добавился новый. В панели справа мы можем видеть детали запроса, заголовки и сам JSON-объект (для удобства чтения выберите пункт Format JSON).

Изучив JSON, вы заметите, что GitHub отправляет исчерпывающую информацию даже для такой простой операции, как комментарий коммита. Для сравнения в новой вкладке браузера перейдите по той же тестовой ссылке для приема запросов. Вы увидите, какую информацию дает «пустой» GET-запрос.

Аналогично можно протестировать другие интересные вам ресурсы. Например, подробное пособие есть у Slack. А Dropbox умеет высылать уведомления на универсальный идентификатор ресурса, когда пользователь вашего приложения вносит изменения в файл.

Отладка вебхуков

Вебхуки являются асинхронным методом, поэтому их отладка может оказаться довольно утомительной. К счастью, есть инструменты, упрощающие этот процесс:

Безопасность использования вебхуков

Если вебхуки доставляют данные в приложение по публичным URL, кто-то может перехватить эти ссылки и подменить ложными данными? Чтобы этого не случилось, вы должны предпринять ряд мер. То, с чего нужно начать – использовать протокол HTTPS. Вы можете пойти дальше и еще больше обезопасить соединение:

Важные замечания

При использовании вебхуков нужно помнить о нескольких важных деталях.

После доставки запроса с данными вебхуки могут перестать отвечать. Это означает, что если в приложении произойдет ошибка, данные могут быть потеряны. Поэтому, чтобы подготовиться к возможным падениям приложения, разберитесь, как провайдер вебхука обрабатывает ответы.

Если на стороне провайдера события происходят часто, такая нагрузка может закончиться падением приложения (как в результате DDoS-атаки). Убедитесь, что клиентское приложение способно обработать ожидаемый масштаб запросов.

Хотя технически вебхуки могут использоваться для передачи массивов данных, рекомендуется использовать их лишь как сигнал изменения состояния. Как только уведомление получено, нужно вызывать безопасный интерфейс API для получения настоящей нагрузки. Такое разделение позволяет повысить масштабируемость и надежность систем обработки данных.

Источник

Что такое Webhook?

Если вы уже занимаетесь автоматизацией вашего бизнеса или только планируете, то вам наверняка уже приходилось сталкиваться с этим малопонятным термином. Итак, многие задаются вопросом, что такое Webhooks? В данном материале мы максимально простыми словами расскажем о том, что это Webhook означает.

Сегодня уже многие знают про API – под этим термином скрывается то, что можно охарактеризовать как специальный язык, который программы используют для общения друг с другом. Используя API, одно приложение может отправить запрос другому для того, чтобы получить в ответ (также при помощи API) какую-либо требуемую информацию.

Для чего используется Webhook

Webhook также используется для того, чтобы различные системы могли обмениваться друг с другом информацией. Вот только «общение» тут происходит по иному принципу. Этот механизм специально создавался для того, чтобы упростить процедуру уведомления о разных событиях – изменении настроек, добавлении нового пользователя, удалении сообщения и т.п.

Принцип работы Webhooks

Принцип работы вебхуки заключается в том, что как только какое-либо событие произошло, об этом сразу же отсылается соответствующее уведомление. И, если в случае с API приложение, которому нужна информация, должно постоянно отправлять запросы типа «это уже случилось?», то при использовании Webhook оно просто ждёт соответствующего уведомления. Единственно что требуется – указать, какие именно сообщения нужно отправлять и куда.

Иными словами, разницу в работе API и Webhook можно описать фразой «не надо постоянно спрашивать меня, произошло ли данное событие, как только оно произойдёт, я сам об этом сообщу». Естественно, что это очень простое описание, но оно хорошо передаёт общий принцип работы «вебхуков».

Осталось только добавить, что термин Webhook появился относительно недавно. Его впервые использовал в 2007 году программист Джефф Линдсей, который и разработал данную технологию. Создавая новое слово, он взял за основу термин «Hook», который программисты используют для описания технологии внесения изменений в стандартное поведение системы.

Вебхуки и Apix-Drive

Налаживая интеграции между системами, мы активно используем, как API, так и Webhooks. Классический пример – интеграция с конструктором сайтов Tilda была реализована именно посредством «вебхуков». Благодаря этому вы можете получать уведомления о самых разных действиях посетителей созданного вами сайта. Например, как только новый покупатель оставит заявку через форму, его контакты будут автоматически внесены в вашу CRM-систему. Применяются «вебхуки» и для интеграции с другими конструкторами сайтов, вроде Bloxy, Landingi и Nethouse.

Ещё примеры использования Webhook – сервис телефонии Telphin, конструктор маркетинговых квизов Enquiz и конструктор чат-ботов Chatra. На самом деле подобных примеров можно привести ещё множество. Но главное тут не в количестве систем, а в простоте их подключения для конечного пользователя.

Для того чтобы наладить интеграцию с любым из подобных сервисов, не нужно понимать глубинные принципы работы технологии Webhook. Отсутствие таких знаний никак не помешает вам наладить связи между самыми разными системами, сделав это просто в несколько кликов мышкой. И никаких сторонних разработчиков, никаких специализированных знаний не потребуется.

Не верите что всё так просто? Зарегистрируйтесь и проверьте на практике!

Источник

Система уведомлений о событиях (Webhooks)

Webhook — механизм оповещения пользователей системы о событиях. События, о которых может уведомлять Webhook:

Webhook используют для отслеживания изменения статусов писем в реальном времени.

Модель, используемая в Webhook, работает следующим образом: при возникновении события установленный ранее обработчик отправляет JSON на URL, который был указан для этого Webhook. Используются стандартные порты: 80 порт для HTTP и 443 порт для HTTPS. Для установки Webhook на URL с указанным портом можно передавать URL в виде: http://11.111.111.11:80

Если URL, на который отправляется Webhook, недоступен (отвечает не HTTP 200 OK, таймаут — 3 секунды), попытки отправки Webhook на этот URL до получения ожидаемого 200 ОК будут продолжаться в течение 24 часов с интервалом в 10 минут с дополнительным параметром retry_count, значение которого будет увеличиваться на 1 с каждой повторной отправкой Webhook.

Если в течение 24 часов вебхук не удалось доставить, попытки отправки прекращаются, а статус вебхука меняется на stopped. На почту аккаунта отправляется уведомление об остановке вебхука с указанием последнего ответа. Чтобы активировать остановленный вебхук, исправьте ошибку, затем включите вебхук с помощью API метода setHook с параметром status=»active» или смените статус в личном кабинете.

Установить обработчик

setHook — установить/заменить обработчик оповещений о событиях определенного типа.

Синтаксис и URL для вызова метода

setHook (hook_url, events, [event_format, max_parallel, single_event, status ])

https://api.unisender.com/ru/api/setHook?api_key=KEY&hook_url=URL&event_format=FORMAT&events[]=EVENT&max_parallel=NUM &single_event=1&status=active

Аргументы

api_key*

ключ доступа к API

hook_url *

на какой URL отправлять запрос при возникновении события. Фактически является идентификатором обработчика. При повторном вызове setHook с таким же hook_url данные обработчика будет заменены.

event_format

формат, в котором передаются данные о событии, обязательный параметр с тремя вариантами значений:

Ключ массива	Описание
email_status	Изменение статуса отправленного email. ok_sent — письмо отправлено; ok_delivered — письмо доставлено; ok_read— письмо прочитано; ok_link_visited — зафиксирован переход по ссылке err_will_retry— письмо не доставлено, но будут попытки отправить его повторно. Другие допустимые значения можно посмотреть здесь. Разрешается использовать только с форматами json_post_gzip и json_post, и запрещается с форматом http_get.
unsubscribe	Изменение статуса подписки получателя (отписался от списка). Допустимое значение:*
subscribe	Изменение статуса подписки получателя (подписался на список). * — отправлять при подписке на любой список id списка — отправлять при подписке на список с заданным id
subscribe_primary	Изменение статуса подписки получателя (подписался на список впервые) Допустимое значение: *
email_check	Добавление подтвержденного обратного адреса. Допустимое значение: *
user_payment	Доступен только для реселлеров. Изменение состояния счета. Учитываются движения, связанные с основным и бонусным счетом. Допустимое значение: *
user_info	Изменение полей информации о пользователе. Допустимое значение: *

max_parallel

необязательное указание максимального количество параллельных вызовов к этому обработчику. По умолчанию равно 10.

single_event

Принимает значения 1 и 0. По умолчанию: 0

1 — оповещение Webhook не содержит массивов, за одно оповещение информация будет возвращаться только по одному событию;
0 — оповещение Webhook возвращает информацию в виде массивов (см. пример ниже).

status

Статус обработчика. Допустимые значения: active — обработчик активен; disabled — обработчик отключён.

Пример вызова

Список обработчиков

listHooks — получить список всех обработчиков.

Синтаксис и URL для вызова метода

listHooks ()

https://api.unisender.com/ru/api/listHooks?api_key=KEY

Аргументы
api_key *	ключ доступа к API

Возвращаемое значение

Удалить обработчик

removeHook — удалить обработчик оповещений.

Синтаксис и URL для вызова метода

removeHook (hook_url)

https://api.unisender.com/ru/api/removeHook?api_key=KEY&hook_url=URL

Аргументы
api_key *	ключ доступа к API
hook_url*	URL-идентификатор удаляемого обработчика

Формат оповещений (JSON)

Пример возвращаемого оповещения

Описание параметров оповещения (для single_event = 0)

Данные оповещения — JSON-объект со следующими полями:

auth MD5-хэш строкового тела сообщения, в котором значение auth заменено на api_key пользователя, чей обработчик вызывается. С помощью этого оповещения получатель может как провести аутентификацию, так и проверить целостность оповещения.

Для генерации auth нужно сформировать полностью тело оповещения в JSON, вместо значения auth подставить значение api_key пользователя и вычислить md5 от тела. Затем заменить в сообщении api_key на получившийся md5, записанный в шестнадцатеричном виде в lowercase.

Для проверки auth надо заменить его значение на api_key, также вычислить md5 от тела оповещения и сверить его со значением auth, полученном в изначальном теле оповещения. num на какой URL в формате punycode отправлять запрос при возникновении события. Фактически является идентификатором обработчика. При повторном вызове setHook с таким же hook_url данные обработчика будет заменены. events_by_user массив из JSON-объектов, каждый элемент которого соответствует одному пользователю. Более одного элемента в этом массиве может быть только для реселлеров — реселлеры могут получить уведомление о событиях сразу нескольких своих пользователей в одном вызове, в остальных случаях этот массив состоит из одного элемента. login логин пользователя, оповещение о событиях которого мы передаём в рассматриваемом элементе массива events_by_user. events массив событий пользователя с вышеуказанным логином, каждый элемент массива имеет следующие поля: