上周对接系统的时候被对接人连续问了三遍webhook是什么，越解释越乱，心里一股火往上窜，明明我自己刚跑通一个测试，张嘴却讲不出一句人话。之前一直以为它就是个简单回调，真要给没接触过开发的人讲清楚，才发现好多模糊的地方自己都没捋顺。
最开始接触它，是要把表单提交的数据同步到另外一个后台。一开始想的办法很笨，写个脚本每隔一段时间就去表单接口拉一遍数据，看看有没有新增记录。跑起来之后问题一堆，间隔设短了，请求就特别多，很多次过去什么新数据都没有，白白消耗资源；间隔设长了，用户提交完表单，要等好久信息才同步过去，业务那边不满意。那段时间反复调轮询的时间，改脚本，越改越烦躁，总觉得这个路子本身就不对。
后来对接的技术说，别轮询了，直接用webhook。当时盯着这个词愣了半天，脑子里还是绕不过来，分不清它和普通接口到底差别在哪。普通接口是我们主动去请求，去问对方拿数据，而webhook反过来，是对方那边一旦触发指定事件，自动往我们提供好的地址推送一条消息。表单有人提交，表单服务自己发起请求，把这条表单数据打包发过来，不用我们不停去问。
把接收地址配进表单平台的设置页，填好地址，保存。随手填了一条测试表单，刷新接收日志，消息一瞬间就到了。没有等待，不用循环查询，事件发生的那一刻推送就触发。那一刻才大概抓住它的样子。
这只是我的个人感受，不是标准答案。
调试的时候踩过不少细碎的坑。推送过来的数据格式是固定的，字段名不对，后端就解析失败，日志里只会看到一条报错，要反复对照对方给的推送示例一点点核对。还有地址必须是公网可以访问到的，本地localhost地址，外面的平台发不过来，一开始卡在这很久，不停疑惑为什么配置完怎么都收不到消息，反复检查参数，最后才想起内网地址外部无法访问这个点。有时候推送还会出现重复推送，平台担心消息丢失，同一个事件会多发一次，业务侧就得自己写逻辑判断，重复的数据不要再入库。
身边还有个同事，用它做消息通知。订单支付成功之后，支付平台通过webhook把支付结果推送到我们服务，收到推送之后，程序自动发通知给用户。他跟我说，对他来说webhook就是事件的通知通道，事件发生是源头，推送是通知动作，接收方拿到通知再跑后续流程。他理解的角度和我最开始从表单同步上手的感受不完全一样，适用场景不一样，感受自然也不一样。
它不是什么复杂的新协议，底层还是http请求，和平时写的接口没有本质区别，区别只在于谁发起请求、什么时候发起请求。普通接口是按需查询，webhook是事件驱动推送。很多人会把它和api混在一起，api范围更大，webhook只是api里面一种特定使用方式。
也不要觉得它万能。不是所有场景都适合换成webhook。如果事件发生频率极低，或者数据不要求实时，继续定时拉取反而更省心，不用额外处理推送重试、重复消息、签名校验这些配套逻辑，维护成本更低。当时我做完表单同步之后，另一个低频次的同步任务，最后还是保留了定时拉取，没有强行改成webhook。
配完签名校验，确认推送来源可信之后，整个链路才算稳妥。签名是对方一起随请求发过来的一串字符，拿约定好的密钥按同样算法计算比对，确认这条推送不是别人伪造发过来的请求，这一步是我后面补上去的，最开始测试的时候嫌麻烦直接跳过，上线前被提醒才加上。
晚上关掉编辑器的时候，屏幕上还留着那条成功推送的日志。没有什么高大上的原理，就是换了一个数据流动的方向而已。