Веб хук как сделать

Веб хук как сделать

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

Начальные требования к подготовке

Для успешного изучения курса и овладения мастерством работы с собственными приложениями для Битрикс24 необходимо владеть (хотя бы на начальном уровне):

• основами PHP;
• основами HTML, CSS;
• опытом работы с API и REST API.

Курс учебный, контрольные тесты и сертификация по нему не предусмотрены.

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.

На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой:

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

Источник

Реализация вебхуков на примере взаимодействия сторонних сервисов с онлайн-кассами

Я попросил нашу команду маркетинга нарисовать иллюстрацию и долго объяснял, что такое вебхуки

Не так давно передо мной встала задача реализовать работу вебхуков в Личном кабинете владельца кассы компании Дримкас. Как оказалось, в сети практически нет описания и туториалов, как это сделать. Я расскажу, как мы это реализовали без тяжелых кронов по БД.

Статья будет полезна для middle node.js-разработчиков.

Где используем вебхуки

Для понимания специфики, придется начать издалека.

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

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

Вебхуки нам понадобились, когда мы подключали к Кабинету интернет-магазины. Для онлайн-торговли тоже нужна касса, только бумажный чек не печатается. Мы решили создать для них инструмент, чтобы они могли из обычного json-а с данными о покупке записать данные о продаже в ФН и передать их в ОФД.

Так как операция фискализации может затянуться на длительное время, превышающее обычный HTTP запрос, нам потребовалось дать возможность узнавать статус этого чека. Каждый раз стучаться в Кабинет за статусом чека не выгодно ни нам, ни Интернет магазину. А с вебхуками убиваем сразу двух зайцев: Кабинет делает запрос только один раз, а интернет-магазин получит чек, как только он будет готов.

Когда мы начали их внедрять, решили дать доступ к этому функционалу сервисам интеграторов. С их помощью сторонние сервисы, которые подключены к Кабинету, получают уведомления о продажах, открытии/закрытии смен, создании и редактировании товаров, внесении и изъятии денег. Мы не остановились до сих пор, и все важные события мы сразу переводим на вебхуки.

Наши требования к вебхукам

Текущий стэк бэкенда

Мы пишем на node.js. В качестве веб фреймворка выбран koa. У нас две базы данных. Postrges с sequelize, где хранятся сильно связанные данные, например, кассы и пользователи. Для хранения несвязанных и неизменяемых данных — чеков, смен — мы используем MongoDB. Ещё повсеместно используются очереди на rabbitMQ, для сглаживания скачкообразных нагрузок. Плюс redis для кэша.

Реализация вебхуков

Определяем события для вызова вебхуков

Для начала определим места, где хотим вызывать вебхуки. На уровне модели мы можем пользоваться хуками в mongoose и в большинстве случаев в sequelize.

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

Когда нет такой проблемы, всё достаточно просто. Пример из модели mongoose:

Подписки на события

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

В бэкэнде мы храним всю информацию о типах событий одним числом, а фронту отправляем готовый json объект:

Чтобы упаковать число в json и извлечь его обратно, мы создаем виртуальные атрибуты в sequelize. В них устанавливаем геттеры и сеттеры. Виртуальные поля вычисляются на лету, изменяют на поля в таблице, но при этом не хранятся БД.

CRUD для управления вебхуками

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

Подготовка к вызовам

Мы не вызываем вебхуки в статическом методе класса Webhook — это позволяет сберечь ресурсы основного сайта. Это работа воркеров — делать фоновые задачи, не мешая работе с REST-API.

Когда на сайте генерируется событие, мы оповещаем воркеров об этом:

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

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

Вызовы и повторные вызовы вебхуков

У нас в стеке используется очереди сообщений. Мы выбрали 5 временных промежутков, и на каждый создали очередь. Если вызов не удался при первой попытке, вебхук переходит в следующую очередь. Когда воркер получает на вход задачу, он откладывает его выполнение на требуемое количество времени от 0 миллисекунд до суток. Через 24 часа мы вызываем вебхук в последний раз и удаляем.

Пример вебхука, который не могут принять в течение суток.

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

Еще 4 факта

• Случается, что задачи попадают в очередь в неправильном порядке — следующая задача в очереди должна быть выполнена раньше текущей. Для нас это не критично. Разница между ними не составит больше 20 секунд — таков наш таймаут запроса.
• В качестве временных интервалов мы выбрали следующий набор значений: 0 секунд, 5 секунд, 1 минута, 1 час, 3 часа и 24 часа.
• Запросы, которые не выполнились в течение 24 часов, не логгируются и не хранятся. Если сторонний сервис имеет downtime сутки, то ничего страшного в неполученных вебхуках нет, потому что проблемы там другого масштаба.
• Если worker не ответит на полученное событие и просто оборвет соединение, то RabbitMQ снова добавит это сообщение в очередь. Таким образом, даже если приложение упало, сам вебхук никуда не пропадет.

Источник

Telegram-бот, webhook и 50 строк кода

Как, опять? Ещё один туториал, пережёвывающий официальную документацию от Telegram, подумали вы? Да, но нет! Это скорее рассуждения на тему того, как построить функциональный бот-сервис используя Python3.5+, asyncio и aiohttp. Тем интереснее, что заголовок на самом деле лукавит…

Так в чём же лукавство заголовка? Во-первых, кода не 50 строк, а всего 39, а во-вторых, и бот не такой сложный, просто эхо-бот. Но, как мне кажется, этого достаточно, чтобы поверить в то, что сделать свой собственный бот-сервис не столь сложно, как может показаться.

Содержание:

1. Что используем

• во-первых, Python 3.5+. Почему именно 3.5+, потому что asyncio [2] и потому что сахарные async, await etc;
• во-вторых, aiohttp. Так как сервис на вебхуках, то он одновременно и HTTP-сервер и HTTP-клиент, а что для этого использовать, как не aiohttp [3];
• в-третьих, почему webhook, а не long polling? Если не планируется изначально бот-рассыльщик, то интерактивность является его основной функцией. Выскажу своё мнение, что для этой задачи, бот в роли HTTP-сервера подходит лучше, чем в роли клиента. Да, и отдадим часть работы (доставку сообщений) сервисам Telegram.

И ещё, у вас должно быть подконтрольное доменное имя, валидный или самоподписанный сертификат. Доступ к серверу на который указывает доменное имя для настройки реверс-прокси на адрес сервиса.

2. Как используем

Сервер

Состояние библиотеки aiohttp на текущий момент таково, что с её использованием можно построить полноценный web-сервер в Джанго-стиле [4].

Для standalone-сервиса вся мощь не пригодится, поэтому создание сервера ограничивается несколькими строками.

N.B. Обратите внимание, что здесь мы определяем роутинг и задаём обработчик входящих сообщений handler.

И стартуем веб-сервер:

Клиент

Для отправки сообщения используем метод sendMessage из Telegram API, для этого необходимо отправить на оформленный должным образом URL POST-запрос с параметрами в виде JSON-объекта. И это мы делаем с помощью aiohttp:

N.B. Обратите внимание, что в случае успешной обработки входящего сообщения и удачной отправки «эха», обработчик возвращает пустой ответ со статусом HTTP 200. Если этого не сделать, сервисы Telegram продолжат в течение какого-то времени «дёргать» запросами хук, либо пока не получат в ответ 200, либо пока не истечёт определённое для сообщения время.

3. Что можно улучшить

Совершенству нет предела, пара идей, как сделать сервис функциональней.

Используем middleware

Допустим, возникла необходимость фильтровать входящие сообщения. Препроцессинг сообщений можно сделать на специальных веб-обработчиках, в терминах aiohtttp — это middlewares [5].

Пример, определяем мидлварь для игнора сообщений от пользователей из черного списка:

И добавляем обработчик при инициализации web-приложения:

Мысли по поводу обработки входящих сообщений

Если бот будет сложнее, чем репитер-попугай, то можно предложить следующую иерархию объектов Api → Conversation → CustomConversation.

Наследуя от Conversation и переопределяя _handler получаем кастомные обработчики, в зависимости от функциональности бота — погодный, финансовый etc.

И наш сервис превращается в ферму:

4. Реальный мир

Регистрация webhook

И вызываем соответствующий метод API любым доступным способом, например:

N.B. Ваш домен, хук на который вы устанавливаете, должен резолвится, иначе метод setWebhook не отработает.

Используем прокси-сервер

Как говорит документация: ports currently supported for Webhooks: 443, 80, 88, 8443.

Как же быть в случае self-hosted, когда необходимые порты уже скорее всего заняты веб-сервером, да и соединение по HTTPS мы в нашем сервисе не настроили?

Ответ простой, запуск сервиса на любом доступном локальном интерфейсе и использование реверс-прокси, и лучше nginx здесь сложно найти что-то другое, пусть он возьмёт на себя задачу организации HTTPS-соединения и переадресацию запросов нашему сервису.

Заключение

Надеюсь, что работа с ботом через вебхуки не показалась сильно сложнее long polling, как по мне так даже проще, гибче и прозрачнее. Дополнительные расходы на организацию сервера не должны пугать настоящего ботовода.

Пусть ваши идеи находят достойный инструмент для реализации.

Источник

Вебхук

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

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

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

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

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

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

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

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

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

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

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

1. Какой-то пользователь публикует сообщение
2. Сообщение появляется в базе данных сервера
3. Сервер вызывает адрес вебхука
4. Программный клиент получает уведомление о том, что доступно новое сообщение

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

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

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

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

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

1. Github — веб-сервис для хостинга IT-проектов и их совместной разработки, использует вебхуки, чтобы оповещать владельцев аккаунтов о новых сообщениях, выпущенных обновлениях, иных события
2. Мой склад — отечественная систему управления торговлей, использует вебхуки для оповещения клиентов о создании покупателями заказов и изменении их статусов, изменении цены товара, обновлении номера телефона контрагента и т.д.
3. Callibri — система коллтрекинга, использует вебхуки для оповещения сторонних систем клиента о совершенных звонках, полученном электронном письме, заявке, сообщении в чате

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

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

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

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

1. Переходим на Webhook.site. Получаем сгенерированный урл, копируем его в буфер обмена
2. Оставляем страницу сервиса открытой. Скопированный адрес передаем провайдеру данных. Для этого используем свой репозиторий на Github. В нем переходим в раздел настроек, выбираем раздел с вебхуками и настраиваем новый
3. Заполняем открывшуюся форму. Вставляем скопированный адрес для отправки запроса. В строке Content type ставим application/json. А затем выбираем события, на которые будет реагировать сервис и отправлять вебхук. Для тестирования инструмента выбираем в качестве интересующего события выбираем публикацию или изменение комментариев к нашему репозиторию. Сохраняем вебхук
4. Оставляем комментарий к коммиту и смотрим на Webhook.site, что получилось
5. Видим, что сразу после публикации комментария поставщик данных отправил на вставленную нами ссылку POST-запрос. Слева размещено оповещение про сам запрос, а справа — детализация. Изучив информацию увидим, что провайдер отправил нам исчерпывающую информацию даже для такого простого события, публикация комментария

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

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

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

1. Pipedream — собирает запросы вебхуков и проверяет их удобным вам способом. Создает общедоступную конечную точку, чтобы получать и проверять HTTP-запросы из любого источника, а также легко проверять заголовки, полезную нагрузку и другие данные
2. Postman — моделирует REST и POST-запросы
3. ngrok — локальный сервер для тестирования программного кода на вашем компьютере
4. httpresponder — сервис для создания конечных точек сбора и ответов на вебхуки в формате JSON или XML-файлов

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

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

1. Использовать HTTPS — это расширение протокола HTTP для поддержки шифрования в целях повышения безопасности
2. Генерировать URLы для отправки вебхуков с уникальными токенами. Например, вот такие: http:suite/index.php?tkn=9e1891552fa7b0c0686b336, где 9e1891552fa7b0c0686b336 — уникальный идентификатор
3. Реализовать базовую идентификацию доступа по технологии HTTP Basic authentication. При получении POST-запроса программный клиент запросит имя пользователя и пароль
4. Работать с поставщиками данных, которые подписывают отправляемые с сервера запросы специальным ключом и проверяют подлинность подписи. Например, тот же Github использует для проверки целостности переданной информации код идентификации HMAC

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

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

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

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

Источник