什么是Webhook?工作原理?如何实现?缺点?

什么是Webhook?工作原理?如何实现?

背景

在使用钉钉机器人配置Stream推送 - 钉钉开放平台,qq机器人(微信没有机器人),企业微信机器人、飞书机器人、GitHub WebHook、腾讯问卷这些应用时,

这些应用都提供了Webhook,它允许系统之间在事件发生时主动传递信息,而无需持续轮询。

有的人一开始可能很困惑,什么是Webhook?如何使用?

什么是 Webhook?

通俗一点就是,你(自己的服务器提供一个webhook)在手机(其它支持webhook的平台注册)上定了一个明天早上6点的闹钟(将自己的webhook注册在其它平台上),当时间来到第二天早上6点时候,手机(其它支持webhook的平台)闹钟响起(触发你注册的webhook),你(自己的服务器提供一个webhook)就会听到铃声响起来(自己的服务器上的webhook触发)。

Webhook 是一种简单的 HTTP 回调机制,它允许一个应用程序在事件发生时自动通过 HTTP 请求通知另一个应用程序。这意味着 Webhook 在某个特定事件发生时,自动向指定的 URL 发送数据,通常是 JSON 或 XML 格式。与传统的 API 不同,Webhook 是一种“推送”机制,而不是“拉取”机制。

Webhook 的工作原理

Webhooks 的工作流程可以总结为以下几个步骤:

  1. 事件触发:当某个应用程序中的特定事件发生时,系统就会触发 Webhook。例如,用户完成了一笔支付,或代码库有新的提交。
  2. 发送 HTTP 请求:事件发生后,应用会通过 HTTP 请求(通常是 POST 请求)将事件数据发送到预设的 URL。这个 URL 是接收 Webhook 的端点,通常是另一个应用程序或服务提供的 API。
  3. 数据处理:接收方应用接收到 HTTP 请求后,会解析请求中的数据,并根据这些数据进行相应的操作。例如,它可能会更新数据库,发送通知,或触发其他操作。

Webhook 与 API 的区别

尽管 Webhook 和传统的 API 都用于系统间的数据交换,它们的工作方式有所不同:

  • Webhook:是一种主动通知机制。当事件发生时,Webhooks 会自动发送数据到指定的 URL,而接收方无需发起请求。
  • API:是一种请求-响应模式。接收方必须主动发起请求来获取数据或执行操作。

因此,Webhooks 更适合处理实时事件和通知,特别是在需要快速响应的场景中,如支付确认、CI/CD 构建等。

Webhook 的常见用途

Webhooks 在很多领域都得到了广泛应用,以下是一些典型的应用场景:

  1. 钉钉机器人:通过使用webhook实现各种事件订阅,让开发者应用程序即可接收到事件内容推送。
  2. 支付系统:支付平台(如 Stripe、PayPal)通常使用 Webhook 来通知商家支付状态的变化。当一个支付成功时,支付平台会触发 Webhook 通知商家进行订单更新或发货操作。
  3. 代码托管平台:像 GitHub 或 GitLab 这样的代码托管平台使用 Webhooks 来通知持续集成(CI)系统代码库的变化。例如,推送新的代码或创建拉取请求时,Webhooks 会触发自动化构建、测试或部署。
  4. 社交媒体平台:社交媒体应用(如 Twitter 或 Facebook)可能会使用 Webhooks 来推送实时更新。例如,当某个用户发布了新内容或有评论时,Webhooks 会通知其他系统进行处理。
  5. 聊天应用:像 Slack 或 Discord 这样的聊天平台允许通过 Webhooks 接收外部系统发送的消息,实时更新聊天频道中的内容。

如何实现 Webhook?

**实际开发中,要实现webhook往往更加复杂,需要做算法安全校验。

各大平台都会提供对应的工具包简化操作,按照对应文档即可快捷操作。

所以这里只是做一个简单demo展示接入流程,并不展示真实接入流程**

实现 Webhook 通常分为两个步骤:设置 Webhook URL 和配置事件触发器。

1. 设置 Webhook URL

接收方服务需要定义一个 Webhook 接口(URL),这个 URL 用于接收来自发送方系统的 HTTP 请求。通常,这个接口会解析 HTTP 请求中的数据,并根据业务需求进行处理。

2. 配置发送方

在发送方应用中(如 GitHub、Stripe 等),需要配置 Webhook。当事件发生时,系统会将相关数据通过 HTTP 请求发送到你设置的 Webhook URL。

以下是几个简单的 Webhook 示例,

下面代码展示了如何在 Python 环境中实现接收 Webhook 请求:

from flask import Flask, request ​ app = Flask(__name__) ​ @app.route('/webhook', methods=['POST']) def webhook():   data = request.json   print("Received webhook data:", data)   # 处理数据,例如触发构建   return 'OK', 200 ​ if __name__ == '__main__':   app.run(debug=True) 
在这个示例中,Flask 用来构建一个简单的 HTTP 服务,接收来自其他应用的 POST 请求,并处理传递的 JSON 数据。

下面展示在node环境中使用 Express 来监听 Webhook 请求。

const express = require('express'); const bodyParser = require('body-parser'); ​ const app = express(); const port = 3000; ​ // 使用 bodyParser 中间件来解析 JSON 请求体 app.use(bodyParser.json()); ​ // 定义 Webhook 路由 app.post('/webhook', (req, res) => { // 打印接收到的数据 console.log('Received Webhook:', req.body); ​ // 你可以根据接收到的数据执行相关操作 // 例如:如果是支付成功的通知,更新订单状态 if (req.body.event === 'payment_success') {   console.log('Payment was successful!');   // 在这里处理支付成功后的业务逻辑 } ​ // 响应 Webhook 请求,告诉发送方我们已成功接收 res.status(200).send('OK'); }); ​ // 启动服务 app.listen(port, () => { console.log(`Webhook server listening at http://localhost:${port}`); }); ​ 
这个应用会启动一个监听在 localhost:3000 的服务器,并在 /webhook 路径上接收 HTTP POST 请求。每当一个 Webhook 请求到达时,它会打印请求的内容,并根据数据执行某些逻辑。
4. 测试Webhool

假设你正在与一个外部服务(例如 钉钉机器人、GitHub 或其他)集成,这些服务会在特定事件发生时向你的 Webhook URL 发送 POST 请求。

Webhook 的安全性

为了防止恶意请求,通常需要对 Webhook 请求进行一些安全检查,比如验证签名或验证请求的来源 IP。

由于 Webhook 机制本身没有内建的身份验证和安全性保障,接收方需要采取额外的安全措施来保护 Webhook 请求不被滥用:

  1. 使用签名验证:发送方可以在 HTTP 请求头中附加签名,接收方则可以验证签名来确认请求的合法性。这种方式可以防止恶意攻击者伪造请求。
  2. IP 地址白名单:为了防止来自不可信来源的请求,可以将发送方的 IP 地址加入白名单,只允许来自这些 IP 的 Webhook 请求。
  3. 验证数据:接收方还可以在处理 Webhook 数据时进行额外验证,确保数据的结构和内容是预期的,避免恶意篡改。

webhook缺点

大部分都是采用 Webhook (注册公网 HTTPS 服务)的方式,包括卡片回调,使用 Webhook 方式开发过程中会遇到较多的问题,包括

  • 申请公网域名和TLS证书
  • 申请公网IP并部署接入网关
  • 部署应用防火墙并配置白名单
  • 独立处理请求的鉴权,以及加解密处理
  • 搭建内网穿透环境进行本地开发调试
针对以上问题,有的应用(例如钉钉)提供了stream模式,使用websocket(这种方式也有缺点)实现同样的操作配置Stream推送 - 钉钉开放平台
WebSocket 和 Webhook 各有优缺点,不能完全替代对方

总结

  • 在你的业务对数据的实时性要求较高时。例如:在新员工入职或者离职,部门变更,需要应用第一时间变更用户数据,此时就可以订阅通讯录事件
  • 你的应用需要及时响应用户的操作时。例如:某用户加入某群聊时,应用可以订阅群变更事件,在用户进入群聊的时候,向用户发送欢迎等信息。

以上只是几个非常简单的使用场景,开发者可以根据不同的事件,进行不同的处理。

Read more

AWS Kiro 账号池管理系统 | 将 Amazon Q Developer API 转换为 OpenAI 兼容格式 | 支持多账号池、OIDC 自动认证、令牌自动刷新、Web 管理控制台 | Go

AWS Kiro 账号池管理系统 | 将 Amazon Q Developer API 转换为 OpenAI 兼容格式 | 支持多账号池、OIDC 自动认证、令牌自动刷新、Web 管理控制台 | Go

Claude API - AWS Kiro 账号池管理 | OpenAI 兼容代理服务 项目地址在wget 里面 web页面访问把后缀.git删掉即可 效果图 AWS Kiro 账号池管理系统 - 将 Amazon Q Developer (Kiro) API 转换为 OpenAI 兼容格式的企业级 Go 代理服务。支持多账号池管理、OIDC 自动认证、令牌自动刷新、流式响应、完整的 Web 管理控制台。 关键词: AWS Kiro, Amazon Q Developer, Claude API, OpenAI Proxy, 账号池管理, OIDC 认证, Go

WebApp 设计中三大关键维度:**导航设计、配置模型与整体设计核心要点**,体现了以用户为中心、兼顾工程可维护性与系统可扩展性的现代 Web 应用设计理念

WebApp 设计中三大关键维度:**导航设计、配置模型与整体设计核心要点**,体现了以用户为中心、兼顾工程可维护性与系统可扩展性的现代 Web 应用设计理念

WebApp 设计中三大关键维度:导航设计、配置模型与整体设计核心要点,体现了以用户为中心、兼顾工程可维护性与系统可扩展性的现代 Web 应用设计理念。 * 导航设计聚焦“用户如何找到并完成目标”,强调错误反馈的友好性、优先级策略(如组 > 单元素)、上下文感知(基于历史行为预判)及无障碍适配(快捷方式、外部链接策略等),本质是构建可预测、可恢复、可个性化的信息寻路系统。 * 配置模型从基础设施视角出发,区分了轻量级(属性列表)与企业级(UML 部署图)表达方式,凸显配置不仅是技术参数集合,更是影响性能、容错、弹性伸缩的关键契约,需在设计早期显式建模与治理。 * WebApp 设计核心要点则锚定质量属性(ISO/IEC 25010 兼容的可用性、安全性、可维护性等)与设计目标(如一致性、健壮性、视觉吸引力),并通过多维并行设计活动(架构/内容/

libwebkit2gtk-4.1-0安装全流程:超详细版配置说明

从零搞定 libwebkit2gtk-4.1-0 安装:开发者避坑全指南 你有没有遇到过这样的场景?刚写好一个基于 GTK4 的 Web 嵌入应用,信心满满地编译运行,结果终端弹出一行红字: error while loading shared libraries: libwebkit2gtk-4.1.so.0: cannot open shared object file 或者更糟——明明安装了库,却提示 undefined symbol: webkit_web_view_new ,程序直接崩溃。 别急,这几乎是每个尝试在 Linux 上集成现代 Web 内容的开发者都会踩的“第一颗雷”。而罪魁祸首,往往就是那个看似普通、实则牵一发而动全身的核心库: libwebkit2gtk-4.1-0 。 今天,

【前端小站】HTML 标签:网页骨架,从空白到惊艳,全靠这些 HTML 标签搞事情

【前端小站】HTML 标签:网页骨架,从空白到惊艳,全靠这些 HTML 标签搞事情

半桔:个人主页  🔥 个人专栏: 《前端扫盲》《手撕面试算法》《C++从入门到入土》 🔖为什么有人总是赞美生活的丰富多彩?我想这是因为他们善于品尝生活中随时出现的意外。 -余华- 文章目录 * 前言 * 一. HTML结构 * 1.1 初始HTML标签 * 1.2 标签的层次 * 二. HTML文本标签 * 2.1 标题标签 * 2.2 段落标签 * 2.3 强调标签 * 2.3.1 加粗 * 2.3.2 倾斜 * 2.3.3 删除线 * 2.3.4 下划线 * 三. 媒体与交互标签 * 3.