ASP.NET WebHook 处理程序

WebHook 接收方验证 WebHook 请求后，用户代码即可对其进行处理。 这是 处理程序 的用处。 处理程序派生自 IWebHookHandler 接口，但通常使用 WebHookHandler 类，而不是直接从接口派生。

WebHook 请求可由一个或多个处理程序处理。 处理程序根据各自的 Order 属性从低到高按顺序调用，其中 Order 是一个简单的整数 (建议介于 1 到 100) 之间：

处理程序可以选择在 WebHookHandlerContext 上设置 Response 属性，这将导致处理停止，并将响应作为 HTTP 响应发送到 WebHook。 在上述情况下，不会调用处理程序 C，因为它的顺序高于 B，B 设置响应。

设置响应通常仅与响应可以将信息带回原始 API 的 WebHook 相关。 例如，在 Slack WebHook 中，响应将发回到 WebHook 来自的通道。 如果处理程序只想从该特定接收器接收 WebHook，则可以设置 Receiver 属性。 如果他们未设置接收方，则为所有接收方调用它们。

响应的另一个常见用途是使用 410 Gone 响应来指示 WebHook 不再处于活动状态，并且不应提交进一步的请求。

默认情况下，处理程序将由所有 WebHook 接收器调用。 但是，如果将 Receiver 属性设置为处理程序的名称，则该处理程序将仅接收来自该接收器的 WebHook 请求。

处理 WebHook

调用处理程序时，它将获取包含 WebHook 请求相关信息的 WebHookHandlerContext 。 数据（通常是 HTTP 请求正文）可从 Data 属性获取。

数据类型通常是 JSON 或 HTML 表单数据，但如果需要，可以强制转换为更具体的类型。 例如，ASP.NET WebHook 生成的自定义 WebHook 可以强制转换为 类型 CustomNotifications ，如下所示：

public class MyWebHookHandler : WebHookHandler
{
    public MyWebHookHandler()
    {
        this.Receiver = "custom";
    }

    public override Task ExecuteAsync(string generator, WebHookHandlerContext context)
    {
        CustomNotifications notifications = context.GetDataOrDefault<CustomNotifications>();
        foreach (var notification in notifications.Notifications)
        {
            ...
        }
        return Task.FromResult(true);
    }
}

排队处理

如果在几秒钟内未生成响应，大多数 WebHook 发送方将重新发送 WebHook。 这意味着处理程序必须在该时间范围内完成处理，才能再次调用它。

如果处理时间更长，或者最好单独处理，则可以使用 WebHookQueueHandler 将 WebHook 请求提交到队列，例如 Azure 存储队列。

此处提供了 WebHookQueueHandler 实现的概述：

public class QueueHandler : WebHookQueueHandler
{
    public override Task EnqueueAsync(WebHookQueueContext context)
    {

        // Enqueue WebHookQueueContext to your queuing system of choice

        return Task.FromResult(true);
    }
}