Поскольку программное обеспечение продолжает поглощать мир, растущее внимание к информации в реальном времени, плавной интеграции и автоматизации выдвинуло веб-перехватчики на передний план современных архитектур приложений. Вебхуки теперь являются основным компонентом управления рабочими процессами на основе событий в реальном времени на разных платформах. Полный отчет вы можете прочитать здесь .
Особая благодарность Оджусу Сэйву из Zoom, Джуди Вандер Слуис из Intuit, Шэрон Еленик из Cloudinary, Саре Эдвардс из Github и Канаду Гупте из ReadMe за сотрудничество с нами при проверке документации веб-перехватчика. Это действительно помогло нам понять, как люди думают о документировании API своих веб-книг, и повлияло на многие наши решения при создании этого отчета.
В этом всеобъемлющем отчете о состоянии веб-перехватчиков в 2023 году мы рассмотрели более 100 ведущих поставщиков API, изучили, как они внедрили веб-перехватчики, а также проанализировали различные способы, которыми эти реализации приняли форму. Применяют ли большинство ведущих поставщиков API лучшие практики? Помимо простого внедрения, как они оптимизировали, защитили и обогатили свои предложения веб-перехватчиков, чтобы удовлетворить потребности сегодняшних разработчиков и предприятий?
Понимая, что в реальных сценариях использования часто возникают реальные факты, мы задействовали нашу собственную клиентскую базу, собрав интригующую статистику, которая проливает свет на реалии доставки веб-перехватчиков. Как часто они ошибаются в дикой природе? Сколько повторений обычно требуется этим сообщениям, прежде чем они успешно попадут в предназначенные для них приложения? Эти статистические данные из первых рук не только дают четкое представление о текущих показателях успешных поставок, но и демонстрируют ценность внедрения передового опыта.
В целом мы обнаружили, что уровень внедрения вебхуков высок — 83%. Однако внедрение большинства передовых практик происходит с задержкой.
Повторные попытки включают повторную отправку веб-перехватчика в случае неудачной попытки. Они имеют решающее значение для надежной службы веб-перехватчиков, поскольку временные проблемы с сетью, простои сервера или другие временные ошибки могут препятствовать немедленной доставке данных.
67% сервисов предлагали автоматические повторные попытки. Наиболее распространенное количество предлагаемых повторных попыток составляет 5, а в большинстве случаев от 3 до 10 повторных попыток. Около 10% служб заявили, что повторили неудачные сообщения, но не предоставили никакой информации о самом графике повторных попыток.
Повторные попытки Webhook используют экспоненциальную задержку для эффективной обработки сбоев, не перегружая принимающий сервер.
Постепенное увеличение времени ожидания между повторными попытками снижает риск усугубления потенциальных проблем с сервером и обеспечивает более адаптивный подход к обработке временных сбоев.
В заключение отметим, что вебхуки используются большинством поставщиков API, но в большинстве случаев они не реализуют лучшие практики. Даже те, кто внедряет большинство лучших практик, делают это по-разному. Пространство настолько фрагментировано, что единственными поставщиками с похожими реализациями были те, которые вообще не внедрили лучшие практики. Надеемся, что этот отчет приведет к увеличению внедрения лучших практик веб-перехватчиков и поможет улучшить опыт разработчиков, использующих веб-перехватчики.
Возможность повторять сообщения вручную ускоряет устранение неполадок. Быстрее немедленно запустить повторную попытку, чем ждать следующей автоматической повторной попытки. Поставщики 12 из 83 указали, что повторные попытки могут быть инициированы вручную. Это была наименее принятая передовая практика.
Для целей тестирования, устранения неполадок и отладки чрезвычайно полезен журнал попыток доставки веб-перехватчиков. Это была вторая наименее используемая функция с показателем внедрения 23%.
Организация событий, предлагаемых потребителям веб-перехватчиков, по типам событий позволяет пользователям выбирать, для каких событий они хотят получать веб-перехватчики, и сокращает количество отправляемых ненужных и нерелевантных сообщений.
93% провайдеров предлагали типы мероприятий. Это наиболее широко распространенная передовая практика, которая, вероятно, связана с тем, что события являются основной ценностью веб-перехватчиков.
Предоставление пользователям возможности аутентифицировать происхождение и содержимое сообщения веб-перехватчика имеет важное значение для обеспечения того, чтобы данные не были подделаны во время передачи, и подтверждает, что они происходят из надежного источника.
45 из 83 поставщиков веб-перехватчиков включили временную метку. Временная метка имеет решающее значение для предотвращения атак повторного воспроизведения.
Хорошее документирование службы веб-перехватчиков может сэкономить время пользователей и избавить их от головной боли.
Наличие примера кода облегчает жизнь разработчикам. Хотя только 43% предлагали образцы кода, включение образцов кода сильно коррелировало с использованием подписей HMACSHA256.
Лучшая документация по веб-перехватчикам дает рекомендации по тестированию реализации веб-перехватчиков. Общие рекомендации включают в себя локальное тестирование веб-перехватчиков (в основном с использованием ngrok), перечисление различных инструментов для запуска конечных точек для получения тестовых сообщений и предоставление возможности отправлять тестовые события.
Существует высокая корреляция между наличием образцов кода и предоставлением рекомендаций и инструментов для тестирования веб-перехватчиков.
В полном отчете мы также представляем некоторые внутренние данные Svix, чтобы увидеть, как часто сообщения терпят неудачу, как часто выполняются повторные попытки, среднее время ответа и средний размер полезной нагрузки сообщений веб-перехватчика.
Чтобы получить больше подобного контента, обязательно подписывайтесь на нас в Twitter , Github или RSS , чтобы быть в курсе последних обновлений службы веб-перехватчиков Svix , или присоединяйтесь к обсуждению в нашем сообществе Slack .