ASP.NET WebHooks 處理常式

WebHook 接收者驗證 WebHook 要求之後，就可以由使用者程式碼處理。 這是 處理常式 的所在位置。 處理常式衍生自 IWebHookHandler 介面，但通常會使用 WebHookHandler 類別，而不是直接從介面衍生。

WebHook 要求可由一或多個處理常式處理。 處理常式會根據其個別 的 Order 屬性依序呼叫，其中 Order 是簡單的整數 (建議介於 1 到 100) ：

處理常式可以選擇性地在 WebHookHandlerCoNtext 上設定 Response 屬性，這會導致處理停止，並將回應傳回為 WebHook 的 HTTP 回應。 在上述情況下，不會呼叫 Handler C，因為它的順序高於 B 和 B 設定回應。

設定回應通常與回應可以傳回原始 API 的 WebHook 相關。 例如，在 Slack WebHook 中，回應會傳回 WebHook 的來源通道。 如果處理常式只想要接收來自該特定接收者的 WebHook，則處理常式可以設定 Receiver 屬性。 如果它們未設定接收者，則會為所有接收者呼叫它們。

回應的另一個常見用法是使用 410 已消失 回應來表示 WebHook 不再作用中，而且不應該提交進一步的要求。

根據預設，所有 WebHook 接收者都會呼叫處理常式。 不過，如果 Receiver 屬性設定為處理常式的名稱，則該處理常式只會接收來自該接收者的 WebHook 要求。

處理 WebHook

呼叫處理常式時，它會取得 WebHookHandlerCoNtext ，其中包含 WebHook 要求的相關資訊。 資料通常是 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);
    }
}