Что такое 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. Отсутствие таких знаний никак не помешает вам наладить связи между самыми разными системами, сделав это просто в несколько кликов мышкой. И никаких сторонних разработчиков, никаких специализированных знаний не потребуется.
Не верите что всё так просто? Зарегистрируйтесь и проверьте на практике!
Вебхуки: как получать данные без промедления и опросов 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 для получения настоящей нагрузки. Такое разделение позволяет повысить масштабируемость и надежность систем обработки данных.
Вебхуки
Механизм вебхуков в МоемСкладе представляет собой мощный и легкий в использовании инструмент для отслеживания изменений в вашем аккаунте. Мы советуем использовать вебхуки, чтобы взаимодействие МоегоСклада с вашим интернет-магазином или приложением в реальном времени, и вы могли избавиться от периодических запросов изменений.
Что такое вебхук?
Непосредственно сам вебхук содержит описание изменения (тип объекта и ссылку на изменившийся объект), которое отправляется на указанный url. Пример тела запроса вебхука:
В чем разница между АПИ и вебхуками
Есть 2 подхода для получения сведений об изменениях в системе: опрос через АПИ (polling) и подписка на вебхуки. Опрос через АПИ предполагает циклические запросы, чтобы получить изменения. Подписка на вебхуки предполагает получение уведомления об изменении в системе. Можно провести следующую аналогию. Предположим вы заказали товар, но его не оказалось в наличии, поэтому вы каждый день звоните в магазин, чтобы узнать о появлении товара, это похоже на опрос через АПИ. Но вы можете просто попросить менеджера в магазине позвонить вам по указанному номеру телефона, когда товар появится, это подписка на вебхуки. Очевидно, что подписка на вебхуки эффективнее и проще, так как гарантируется оперативное получение изменений в системе и меньшая нагрузка на клиентское приложение.
Когда нужно использовать АПИ, а когда вебхук
Несмотря на преимущество использования вебхуков, важно понимать, что подписка на вебхуки это всего лишь форма уведомления об изменениях в системе. Действия с сущностями (CRUD) необходимо выполнять с помощью АПИ.
Возможные сценарии, когда подписка на вебхуки выглядит предпочтительнее опросов через АПИ:
Как использовать вебхуки через JSON API
Вебхуки в JSON API
Работа с вебхуками в МоемСкладе возможна только через JSON API. Методы работы с вебхуками позволяют создать, удалить, обновить, получить и отключить вебхуки.
Ключевыми признаками вебхука являются адрес отправки (url), тип сущности (entityType) и тип события (action). Пара признаков (entityType и action) должна быть уникальной, т.е. не может повторяться в других вебхуках. Существуют следующие типы событий (action):
Данные типы событий могут быть применимы ко всем типам сущностей (базовые сущности и документы). Обратите внимание, что отчеты и аудит не являются сущностями.
Рассмотрим методы работы с вебхуками. Для создания вебхука достаточно указать url, entityType и action, как в примере ниже
В ответ должен придти json, содержащий описание вебхука
Как и в других запросах сущностей JSON API другие действия над вебхуками возможны только при указании идентификатора. В полученном json поле id. Пример получения вебхука по идентификатору.
У вебхука можно изменить поля, указанные при создании, а также включить/отключить его. Для этого выполняется PUT запрос с указанием идентификатора. Пример запроса с изменением события
Пример запроса с отключением вебхука.
Удаление вебхука выполняется по аналогии, но только используется метод DELETE.
Получить все вебхуки можно с помощью типичного GET запроса.
В ответ придет коллекция вебхуков.
Ограничения при работе с вебхуками
При работе с вебхуками есть ряд важных замечаний:
Отправка вебхука в клиентское приложение
МойСклад отправляет вебхук в клиентское приложение с помощью метода POST, указывая заголовок User-Agent со значением MoySklad webhook touch agent 1.0 (/https://www.moysklad.ru).
При отправке уведомления вебхука, МойСклад ожидает ответ от клиентского приложения со статусом 200 или 204, чтобы считать уведомление доставленным. При невалидном ответе от клиентского приложения наша система осуществляет еще 3 попытки отправки. Данные попытки осуществляются последовательно, без таймаутов между ними. Если все попытки закончились неудачно, то данное уведомление считается неотправленным и в дальнейшем удаляется, в клиентское приложение оно отправлено не будет, т.к. проблема на стороне клиентского приложения.
Как проверить, что вебхук работает?
обзор webHooks ASP.NET
WebHooks представляет собой легкий шаблон HTTP, обеспечивающий простую модель паб/суб для проводки web-aIS и сервисов SaaS. Когда событие происходит в службе, уведомление отправляется в виде запроса HTTP POST зарегистрированным абонентам. Запрос POST содержит информацию о событии, которая позволяет получателю действовать соответствующим образом.
Из-за своей простоты, WebHooks уже подвергаются большое количество услуг, включая Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Полоса, Trello, и многое другое. Например, WebHook может указать, что файл изменился в Dropbox,или изменение кода было зафиксировано в GitHub, или платеж был инициирован в PayPal, или карта была создана в Trello. Возможности безграничны!
Корпорация Майкрософт ASP.NET WebHooks упрощает отправку и получение WebHooks как части приложения ASP.NET:
Что касается принимающей стороны, то она обеспечивает общую модель для приема и обработки WebHooks от любого числа поставщиков WebHook. Он выходит из коробки с поддержкой Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello,WordPress и Zendesk, но это легко добавить поддержку для более.
На стороне отправки он обеспечивает поддержку для управления и хранения подписок, а также для отправки уведомлений о событиях в нужный набор абонентов. Это позволяет определить свой собственный набор событий, на которые подписчики могут подписаться, и уведомить их, когда что-то происходит.
Эти две части могут быть использованы вместе или друг от друга в зависимости от вашего сценария. Если вам нужно только получать WebHooks от других служб, то вы можете использовать только часть приемника; если вы только хотите разоблачить WebHooks для других потреблять, то вы можете сделать именно это.
Код нацелен ASP.NET Web API 2 и ASP.NET MVC 5 и доступен в качестве OSS на GitHub.
Обзор WebHooks
WebHooks — это шаблон, который означает, что он изменяет, как он используется от службы к службе, но основная идея та же. Вы можете думать о WebHooks как простой паб / суб-модель, где пользователь может подписаться на события, происходящие в другом месте. Уведомления о событии распространяются как запросы HTTP POST, содержащие информацию о самом событии.
Обычно запрос HTTP POST содержит данные об объекте JSON или HTML-формы, определенные отправителем WebHook, включая информацию о событии, вызывающую срабатывание WebHook. Например, тело запроса WebHook POST от GitHub выглядит следующим образом в результате открытия новой проблемы в определенном репозитории:
Чтобы убедиться, что WebHook действительно от предполагаемого отправителя, post запрос защищен в некотором роде, а затем проверить приемник. Например, GitHub WebHooks включает в себя заголовок X-Hub-Signature HTTP с хэшом органа запроса, который проверяется реализацией получателя, так что вам не придется беспокоиться об этом.
Поток WebHook обычно идет что-то вроде этого:
Отправитель WebHook предоставляет события, на которые клиент может подписаться. События описывают наблюдаемые изменения в системе, например, что был вставлен новый элемент данных, что процесс завершен, или что-то еще.
Приемник WebHook подписывается, регистрируя WebHook, состоящий из четырех вещей:
URI, где уведомление о событии должно быть размещено в виде запроса HTTP POST;
Набор фильтров, описывающих конкретные события, для которых webHook должен быть уволен;
Секретный ключ, который используется для подписания запроса HTTP POST;
Дополнительные данные, которые должны быть включены в запрос HTTP POST. Это могут быть, например, дополнительные поля заголовка HTTP или свойства, включенные в орган запроса HTTP POST.
Как только событие происходит, соответствующие регистрации WebHook найдены и http POST запросы представлены. Как правило, генерация запросов HTTP POST повторно повторяется несколько раз, если по какой-то причине получатель не отвечает или запрос HTTP POST приводит к ответу на ошибку.
Конвейер обработки WebHooks
Конвейер обработки ASP.NET WebHooks для входящих WebHooks выглядит следующим образом:
Двумя ключевыми концепциями здесь являются приемники и обработчики:
Получатели несут ответственность за обработку конкретного вкуса WebHook от данного отправителя и для обеспечения проверки безопасности, чтобы убедиться, что запрос WebHook действительно от предполагаемого отправителя.
Обработчики, как правило, где пользовательский код работает обработки конкретного WebHook.
В следующих узлах эти понятия описаны более подробно.
API, WebSocket или WebHook: что выбрать?
Apr 19 · 4 min read
В любом приложении нужен надежный механизм взаимодействия между его компонентами.
Например, в веб-приложениях необходимо взаимодействие между браузером и сервером. Иногда серверу нужно отправить сообщения обратно в браузер. И бывают случаи, когда бэкенд зависит от другого сервиса, на завершение которого уходит много времени.
В этих и других ситуациях используются API, WebSocket и WebHook. Это три образцовых механизма передачи и синхронизации данных между различными частями приложения.
Фактически они занимаются одним и тем же — обеспечивают обмен данными. Тем не менее между ними есть ряд существенных различий. В статье мы рассмотрим, как работают эти три подхода и как выбрать наиболее подходящий из них в зависимости от конкретных сценариев.
API предоставляет интерфейс и контракт для потребителей
API или интерфейс прикладного программирования — это контракт между потребителем и поставщиком сервиса, который обычно предоставляет API через HTTP.
Особенно хорош он для CRUD-операций (т. е. базовых операций управления данными) из веба, для мобильных устройств или даже межсервисной интеграции. В качестве формата передачи данных при осуществлении таких взаимодействий используются в основном JSON или XML.
Рассмотрим сценарий, в котором пользователи ищут товары в интернет-магазине. Отправив поисковый запрос на нужный товар, пользователь в считанные секунды получает ответ. Схема работы API предельно проста:
API-запросы инициирует потребитель. Поэтому они хорошо подходят для таких задач, как сохранение состояния или выполнение быстрого действия для получения немедленного ответа от серверной операции.
Если же серверу необходимо снова связаться с браузером, то при использовании API нет прямого способа это сделать (разве что браузер будет периодически проверять наличие обновлений).
Например, на задачи типа формирования отчетов расходуется больше времени и ресурсов там, где они обычно выполняются в фоновом режиме. Получается, что потребитель сообщает поставщику сервиса о необходимости сгенерировать отчет, но напрямую уведомить потребителя о завершении отчета нет возможности. Браузеру в этом случае потребуется постоянно опрашивать API.
Но маркерный доступ здесь неэффективен. Для решения таких задач есть методы получше.
WebSockets — когда нужно взаимодействовать в режиме реального времени
Такие задачи решает WebSocket, обеспечивающий постоянный и двунаправленный обмен данными между потребителем и поставщиком сервиса.
Наличие полнодуплексного канала связи позволяет поставщикам сервисов отправлять сообщения в любое время. И это лучшее решение для веб-приложений реального времени, ведь WebSocket поддерживают все современные браузеры.
Однако при постоянно открытом соединении увеличивается расход ресурсов и энергопотребление (для мобильных устройств), к тому же затрудняется масштабирование.
Например, в том же сценарии с генерированием отчетов использование WebSocket является отличным вариантом для веба. А вот для мобильных устройств, где используются технологии типа push-уведомлений, это не лучший вариант. Не самым оптимальным решением WebSocket будет и для связи бэкенда с внешним сервисом, в случае если последний требуется бэкенду для генерирования отчета.
Здесь нужен такой механизм, как WebHook.
WebHook — идеальный вариант для обратных вызовов бэкенда
WebHook (вебхук) решает проблемы, появляющиеся при использовании WebSocket. Каким образом? Задействуя механизм получения ответа от поставщика сервиса, причем этот механизм не требует соединения.
Технически это выглядит следующим образом. Потребитель регистрирует вебхук (URL-адрес обратного вызова) в поставщике сервиса, и этот URL-адрес будет местом для получения данных от вебхука.
Чаще всего этот URL-адрес принадлежит другому серверу. Вебхуки в основном и используются для взаимодействия между серверами или бэкенд-процессами.
Рассмотрим подробнее, как работает вебхук. Здесь различаются четыре части.
На первый взгляд, создается впечатление, что вебхуки и API прямо противоположны друг другу, и по этой причине многие называют вебхуки механизмами, обратными API.
Подведем итоги
Вебхуки, WebSocket и API используются в различных ситуациях для осуществления обмена данными.
API лучше подходят для приложений, в которых нужны только базовые CRUD-операции и синхронные запрос-ответ. Кроме того, API без проблем используются с мобильными и веб-приложениями, а также при интеграции сервисов.
Если же веб-приложению нужно взаимодействовать с бэкендом в режиме реального времени, следует выбрать WebSocket. Он позволяет установить двусторонний канал связи между браузером и бэкендом.
Вебхуки немного отличаются от API и WebSocket и больше походят на механизмы, обратные API: потребитель регистрирует URL-адрес вебхука в поставщике сервиса, который в нужный момент вызывает вебхук.