Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Warnung
ASP.NET WebHooks veraltet ist und keine Updates oder Sicherheitsupdates mehr erhält.
WebHooks ist ein einfaches HTTP-Muster, das ein einfaches Pub/Sub-Modell zum Verkabeln von Web-APIs und SaaS-Diensten bereitstellt. Wenn ein Ereignis in einem Dienst auftritt, wird eine Benachrichtigung in Form einer HTTP POST-Anforderung an registrierte Abonnenten gesendet. Die POST-Anforderung enthält Informationen zum Ereignis, die es dem Empfänger ermöglicht, entsprechend zu handeln.
Aufgrund ihrer Einfachheit werden WebHooks bereits von einer großen Anzahl von Diensten verfügbar gemacht, einschließlich Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello und vieles mehr. Beispielsweise kann ein WebHook angeben, dass sich eine Datei in Dropbox geändert hat. oder eine Codeänderung wurde in GitHub übernommen, oder eine Zahlung wurde in PayPal oder eine Karte in Trello erstellt. Die Möglichkeiten sind endlos!
Microsoft ASP.NET WebHooks erleichtert das Senden und Empfangen von WebHooks als Teil Ihrer ASP.NET-Anwendung:
Auf der empfangenden Seite wird ein gemeinsames Modell zum Empfangen und Verarbeiten von WebHooks von einer beliebigen Anzahl von WebHook-Anbietern bereitgestellt. Es kommt aus der Box mit Unterstützung für Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello,WordPress und Zendesk aber es ist einfach, weitere Unterstützung hinzuzufügen.
Auf der sendenden Seite bietet sie Unterstützung für das Verwalten und Speichern von Abonnements sowie für das Senden von Ereignisbenachrichtigungen an die richtige Gruppe von Abonnenten. Auf diese Weise können Sie Ihre eigenen Ereignisse festlegen, die Abonnenten abonnieren können, und diese benachrichtigen, wenn diese Ereignisse eintreten.
Je nach Szenario können die beiden Teile zusammen oder voneinander getrennt verwendet werden. Wenn Sie nur WebHooks von anderen Diensten empfangen müssen, können Sie nur den Empfängerteil verwenden. Wenn Sie nur WebHooks für andere Dienste verfügbar machen möchten, können Sie dies tun.
Der Code zielt auf ASP.NET-Web-API 2 und ASP.NET MVC 5 ab und ist als OSS auf GitHub verfügbar.
Übersicht über WebHooks
WebHooks ist ein Muster, das bedeutet, dass es von Dienst zu Dienst verwendet wird, aber die Grundidee ist identisch. Sie können sich WebHooks als einfaches Pub/Sub-Modell vorstellen, bei dem ein Benutzer Ereignisse an anderer Stelle abonnieren kann. Die Ereignisbenachrichtigungen werden als HTTP POST-Anforderungen weitergegeben, die Informationen über das Ereignis selbst enthalten.
In der Regel enthält die HTTP POST-Anforderung ein JSON-Objekt oder HTML-Formulardaten, die vom WebHook-Absender bestimmt werden, einschließlich Informationen zum Ereignis, das den WebHook auslöst. Ein WebHook POST-Anforderungstext aus GitHub sieht beispielsweise wie folgt aus, weil ein neues Problem in einem bestimmten Repository geöffnet wird:
{
"action": "opened",
"issue": {
"url": "https://api.github.com/repos/octocat/Hello-World/issues/1347",
"number": 1347,
...
},
"repository": {
"id": 1296269,
"full_name": "octocat/Hello-World",
"owner": {
"login": "octocat",
"id": 1
...
},
...
},
"sender": {
"login": "octocat",
"id": 1,
...
}
}
Um sicherzustellen, dass der WebHook tatsächlich vom beabsichtigten Absender stammt, wird die POST-Anforderung auf irgendeine Weise gesichert und dann vom Empfänger überprüft. Beispielsweise enthält GitHub WebHooks einen X-Hub-Signature HTTP-Header mit einem Hash des Anforderungstexts, der von der Empfängerimplementierung überprüft wird, damit Sie sich keine Gedanken darüber machen müssen.
Der WebHook-Fluss sieht im Allgemeinen wie folgt aus:
Der WebHook-Absender macht Ereignisse verfügbar, die ein Client abonnieren kann. Die Ereignisse beschreiben feststellbare Änderungen am System, z. B. dass ein neues Datenelement eingefügt wurde, dass ein Prozess abgeschlossen wurde oder etwas anderes.
Der WebHook-Empfänger abonniert, indem ein WebHook registriert wird, der aus vier Elementen besteht:
Ein URI für den Ort, an dem die Ereignisbenachrichtigung in Form einer HTTP POST-Anforderung gepostet werden soll;
Eine Reihe von Filtern, die die speziellen Ereignisse beschreiben, für die der WebHook ausgelöst werden soll;
Ein geheimer Schlüssel, der zum Signieren der HTTP POST-Anforderung verwendet wird;
Zusätzliche Daten, die in die HTTP POST-Anforderung aufgenommen werden sollen. Dies kann z. B. zusätzliche HTTP-Headerfelder oder -Eigenschaften sein, die im HTTP POST-Anforderungstext enthalten sind.
Sobald ein Ereignis auftritt, werden die übereinstimmenden WebHook-Registrierungen gefunden, und HTTP POST-Anforderungen werden übermittelt. In der Regel wird die Generierung der HTTP POST-Anforderungen mehrmals wiederholt, wenn der Empfänger aus irgendeinem Grund nicht antwortet oder die HTTP POST-Anforderung zu einer Fehlerantwort führt.
WebHooks-Verarbeitungspipeline
Die Microsoft ASP.NET WebHooks-Verarbeitungspipeline für eingehende WebHooks sieht wie folgt aus:
Die beiden wichtigsten Konzepte sind Empfänger und Handler:
Empfänger sind für die Behandlung der bestimmten Variante von WebHook von einem bestimmten Absender und für die Durchführung von Sicherheitsüberprüfungen verantwortlich, um sicherzustellen, dass die WebHook-Anforderung tatsächlich vom vorgesehenen Absender stammt.
Handler sind in der Regel der Ort, an dem der benutzerdefinierte Code das bestimmte WebHook verarbeitet.
In den folgenden Knoten werden diese Konzepte ausführlicher beschrieben.