想象一下，我有一个（ReST）API，它提供对资源版本的访问。为了实现较低的延迟，我想在新资源可用时推出新资源的通知。一种方法是使用webhooks。 Webhook似乎通常被视为寿命长（几天，几周...）或半永久性资源。 如今，我们现在可以升级相对短时间的低延迟会话的websocket连接。
我认为，客户创建临时的Webhook来接收实时通知仍然有中间立场。 对于半永久资源，由客户端管理订阅是有意义的。 对于短暂的Webhook，我们需要服务器来管理Web Hook的生命周期，以防客户端忘记删除它们本身。
我还没有在网上看到关于这种Webhook的任何讨论。 临时Webhook 是正确的术语吗？
有什么最佳实践，何时可以自动删除它们？
如果客户端忘记了或无法发送DELETE，则服务器应在何时删除资源？ 对原始POST的回复是否应包含生存时间？ 是否应该定期发布探针心跳并在N次尝试后仍无答复，保持挂机状态？ 当服务器决定/ foobar / webhooks /可以被删除时，应该变成410 GONE还是404？
这里似乎有一定的标准化余地，可以避免所有潜在的陷阱。
我会接受一个答案（也欢迎大家提出意见），这个答案会自己改进，并链接到一个或多个记录良好的方法或描述一些好的模式。
答案 0 :(得分：0)
我的猜测是这样的：
特定的网络挂钩位于 / foobar / webhooks /
客户端将HTTP POST发送到 / foobar / webhooks 以创建订阅。
客户端可以选择指出需要多长时间。
服务器回复202 ACCEPT和Webhook的位置 / foobar / webhooks /
该webhook应该提供生存时间指示。
完成后，客户端将HTTP DELETE发送到 / foobar / webhooks /
如果客户端希望挂钩持续更长的时间，则应通过将消息发布到 / foobar / webhooks / 来告知服务器，并要求其保留该消息 钩的寿命更长。
您还需要注意安全性，here对此进行了很好的讨论。