[Feature] 提供一个 API 允许应用端动态注册 WebHook 地址

[frg2089]

我在写 这条评论¹ 的时候想到现在的 WebHook 是在协议端那里写死（配置文件）固定的
可以考虑提供一个 API 允许应用端向协议端动态注册 WebHook 地址

Important

为避免被滥用 这个 API 必须只允许携带 access_token 的请求访问
避免随随便便被别人当枪使（指应用端指定随便一个其他域名 然后协议端就不断的向目标发垃圾）

Footnotes

1. https://github.com/SaltifyDev/milky/issues/90#issuecomment-4015639815 ↩

[Wesley-Young]

需要讨论的问题：

• 实际意义有多大？

应用端不一定了解自己是否公网可达，因此我个人认为这一行为难以通用。

• 动态注册 WebHook 的生命周期应该是多久？

毕竟 HTTP 请求是无状态的，协议端无法预知一个应用端的生命周期何时结束，也许应该引入显式的反注册（un-register）机制？

• 如果 WebHook 地址不可达应该如何处理？

我倾向于在注册时就进行一次 Pre-flight check，如果不可达，API 直接报错。

• 如何限制 “仅允许携带 access_token 的请求”？

我认为这个就不属于普通 API 的范畴了，如有必要可以在 /api 和 /event 之外再开一个 Endpoint 用来实现该功能

[frg2089]

• 实际意义有多大？

一拍脑门决定的 可能就是把原本需要协议端配置文件写死的东西移到应用端（？

应用端不一定了解自己是否公网可达

我认为这是想用 WebHook 方案的用户该考虑的事 这应该属于高级操作
因为应用端连自己的域名是什么都不知道 是需要用户手动配置的（总不能靠 DNS 反查吧）

• 动态注册 WebHook 的生命周期应该是多久？
• 如果 WebHook 地址不可达应该如何处理？

如果能建立连接就一直保留 当连接失败时按这样的规律重试
1次 等待1秒
2次 等待5秒
3次 等待10秒
如果还连不上则放弃连接并认为已经失效

也许应该引入显式的反注册（un-register）机制？

可以引入 但我认为依靠应用端来反注册它是不可靠的 所以必须要有上述的失效机制