Realisierung von Publish-/Subscribe-Szenarien via HTTP

ASP.NET WebHooks: Publish-/Subscribe via HTTP
Kommentare

ASP.NET WebHooks unterstützt bei der Realisierung von Publish-/Subscribe-Szenarien via HTTP. Es bietet eine breite Unterstützung für etablierte Webangebote, wie Dropbox, GitHub oder WordPress und erlaubt auch das Bereitstellen von Erweiterungspunkten in eigenen Lösungen.

Niemand ist eine Insel. Das gilt auch für Softwaresysteme. Vielmehr greifen sie immer häufiger ineinander, um betriebliche Abläufe zu unterstützen. Zur Kommunikation zwischen Anwendungen stehen verschiedene Ansätze zur Verfügung. Einer davon firmiert unter Publish/Subscribe und erlaubt frei nach dem Hollywood-Prinzip „Don’t call us, we‘ll call you“ das Versenden von Benachrichtigungen beim Eintreten von Ereignissen.

Bei WebHooks handelt es sich um ein etabliertes Muster, das von vielen Angeboten zur Realisierung solcher Szenarien via HTTP genutzt wird. Mit ASP.NET WebHooks befindet sich in der ASP.NET-Familie nun ein neues Framework, das die Umsetzung dieses Musters vereinfacht. Es liegt derzeit als Betaversion vor und kann sich somit bis zur finalen Veröffentlichung noch ändern.

Dieser Artikel beschreibt die Nutzung von ASP.NET WebHooks anhand zweier Beispiele. Den vollständigen Quellcode stellt der Autor auf GitHub zur Verfügung.

WebHooks – das steckt dahinter

Die Idee hinter WebHooks ist eine einfache: Eine Anwendung, die als Abonnent (Subscriber) auftritt, möchte sich über Ereignisse eines Verlegers (Publisher) informieren lassen. Aus diesem Grund registriert sich der Abonnent unter Angabe eines URL beim Verleger. Immer, wenn beim Verleger ein Ereignis auftritt, ruft er diesen URL auf, um den Abonnenten zu benachrichtigen und übersendet dabei Informationen über das aktuelle Ereignis. Je nach Implementierung können Abonnenten auch angeben, dass sie nur über bestimmte Ereignisse informiert werden möchten.

Um zu verhindern, dass Angreifer Informationen an den Abonnenten senden, hinterlegt der Abonnent beim Registrieren ein Geheimnis. Dieses kann mit einem Passwort verglichen werden. Der Verleger präsentiert dieses Geheimnis im Zuge von Benachrichtigungen, um zu beweisen, dass er tatsächlich der Verleger ist, der er vorgibt zu sein. Alternativ dazu lässt er dieses Geheimnis in eine Prüfsumme (HMAC) für die übersendeten Informationen einfließen. Durch das Inkludieren dieser Prüfsumme in eine Kopfzeile beweist er dem Abonnenten anschließend seine Identität, ohne das Geheimnis zu erwähnen.

API Summit 2017

Web APIs mit moderner Web-Technologie konsumieren

mit Rainer Stropek (software architects)

API First mit Swagger & Co.

mit Thilo Frotscher (Freiberufler)

Damit Angreifern, die sich als Abonnenten ausgeben, keine sensiblen Daten in die Hände fallen, können sich Verleger entscheiden, nur wenige unverfängliche Informationen über Ereignisse zu versenden. Beispielsweise könnten sie sich auf eine Ereignis-ID beschränken. Um an sämtliche Informationen über das Ereignis zu kommen, muss der Abonnent eine Anfrage an den Verleger richten und sich dabei authentifizieren.

Die Idee hinter WebHooks funktioniert nur dann, wenn der URL des Abonnenten für den Verleger erreichbar ist. Das ist zum Beispiel nicht der Fall, wenn der Abonnent durch eine Firewall abgeschottet ist. Aus diesem Grund eignen sich WebHooks lediglich für die Kommunikation zwischen serverseitigen Anwendungen. Für die Kommunikation zwischen serverseitigen Anwendungen und Clients sind sie hingegen nicht geeignet, da Letztere in der Regel durch eine Firewall geschützt sind. Für solche Szenarien eigenen sich Ansätze wie Long Polling oder WebSockets besser. Eine Implementierung dieser Ansätze bietet beispielsweise das Framework ASP.NET SignalR.

ASP.NET WebHooks

ASP.NET WebHooks hilft bei der Realisierung des namensgebenden Musters. Es unterstützt sowohl die Implementierung von Verlegern als auch die von Abonnenten. Da es sich bei WebHooks lediglich um ein Muster und nicht um einen Standard handelt, stellt das ASP.NET-Team für die Interaktion mit bekannten Webangeboten, die als Verleger auftreten, eigene Pakte zur Verfügung. Laut Henrik F Nielsen liegt somit out of the box eine Unterstützung für Azure Alerts, Dropbox, GitHub, Kudu, Instagram, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello und WordPress vor. Eine Unterstützung für weitere Anbieter kann der Entwickler laut Aussagen von Microsoft unter Nutzung des gebotenen Funktionsumfangs realisieren.

Zur Bereitstellung von Web-APIs stützt sich ASP.NET WebHooks auf das Schwesterframework ASP.NET Web API. Damit spendiert es dem Verleger beispielsweise ein Web-API zum Registrieren von Abonnenten. Aber auch die Abonnenten erhalten ein Web-API. Dieses ruft der Verleger im Rahmen von Benachrichtigungen auf. Dabei erfolgt auch die Validierung des oben diskutierten Geheimnisses, das der Abonnent bei der Registrierung erhält.

Um auf Benachrichtigungen zu reagieren, stellt der Entwickler dem Abonnenten einen oder mehrere WebHookHandler zur Verfügung. Dabei handelt es sich um Implementierungen des Interface IWebHookHandler. Jeder WebHookHandler kann angeben, für welche WebHooks er sich interessiert. Erhält das Web-API des Abonnenten eine Benachrichtigung, so delegiert sie an sämtliche WebHookHandler, die für den betroffenen WebHook in Frage kommen. Die Reihenfolge, in der sie die einzelnen Handler aufruft, kann der Entwickler durch das Vergeben einer Ordnungszahl für die einzelnen Handler beeinflussen. Jeder Handler kann diese Aufrufkette jedoch unterbrechen, indem er eine HTTP-basierte Antwort für den Verleger retourniert. Damit kann er zum Beispiel auf einen Fehler hinweisen. In diesem Fall ruft das Web-API nachgelagerte Handler nicht auf. Liefert kein Handler eine Antwort, zieht das Web-API eine Standardantwort heran.

Zur Nutzung von WebHooks stellt ASP.NET WebHooks auch Routinen für ASP.NET Web API und ASP.NET MVC zur Verfügung. Über diese können Controller des Verlegers beispielsweise Nachrichten veröffentlichen. Auch zum Persistieren von Abos bietet WebHooks eine Lösung. Die damit einhergehenden Informationen können derzeit in einem Azure-Storage-Konto gespeichert werden. Die dafür verantwortliche Komponente ist jedoch, wie viele andere von WebHooks bereitgestellte Komponenten, austauschbar, sodass der Entwickler auch andere Datenspeicher nutzen kann. Darüber hinaus ist zu erwarten, dass es früher oder später auch Unterstützung für SQL Server und/oder Entity Framework geben wird. Nutzt der Entwickler keine solche Komponente, verwaltet WebHooks die einzelnen Abos im Hauptspeicher.

Abonnenten mit ASP.NET WebHooks bereitstellen

Zum Einstieg in die Welt von ASP.NET WebHooks beschreibt dieser Abschnitt die Entwicklung eines einfachen Abonnenten für GitHub. Dieser lässt sich bei jedem Ereignis benachrichtigen, das bei einem konfigurierten Repository auftritt. Beispiele für solche Ereignisse sind das Einchecken von Quellcode (push) oder das Hinzufügen von Aufgaben. Das für die Interaktion mit GitHub via NuGet bereitgestellte Paket nennt sich Microsoft.AspNet.WebHooks.Receivers.GitHub. Um den sich darin befindlichen Empfänger (Receiver) für Nachrichten von GitHub zu aktivieren, ist der Aufruf der folgenden Erweiterungsmethode für das Konfigurationsobjekt von ASP.NET Web API notwendig:

config.InitializeReceiveGitHubWebHooks();

Dazu bietet sich bei Nutzung der Projektvorlage von Visual Studio die Datei App_Start/WebApiConfig.cs an. Darüber hinaus ist der Anwendung das Geheimnis, das sich der Abonnent mit dem Produzenten teilt, bekanntzugeben. Standardmäßig bezieht der GitHub-Receiver dazu die Konfigurationseinstellung MS_WebHookReceiverSecret_GitHub aus der web.config:

<appSettings>
  <add key="MS_WebHookReceiverSecret_GitHub" value="[…]"/>
</appSettings>

Das vergebene Geheimnis muss aus mindestens sechzehn Zeichen bestehen. Ist dies nicht der Fall, verweigert WebHooks zur Laufzeit den Dienst. Durch das Bereitstellen einer eigenen Implementierung des Interface IWebHookReceiverConfig kann der Entwickler das Framework veranlassen, diese Konfigurationseinstellung auf anderer Weise zu ermitteln, zum Beispiel über eine Datenbank.

Jeder Abonnent kann beim selben Verleger mehrere Abos abschließen: Ein unbenanntes und weitere benannte, die eine ID zugewiesen bekommen. Existieren mehrere Abos, sind deren Geheimnisse kommasepariert in die gezeigte Konfigurationseinstellung aufzunehmen. Den Geheimnissen der benannten Abos ist die jeweilige Abo-ID voranzustellen:

<secret>, Abo1=<secret-1>, Abo2=<secret-2>

WebHookHandler zur Behandlung von Ereignissen

Zur Behandlung von Ereignissen stellt der Abonnent eine oder mehrere Implementierungen des Interface IWebHookHandler bereit. ASP.NET WebHooks sucht beim Programmstart diese Klassen und registriert sie zur späteren Verwendung. Um den Umfang mit IWebHookHandler ein wenig zu vereinfachen, stellt das Framework die abstrakte Klasse WebHookHandler zur Verfügung, die IWebHookHandler implementiert. Listing 1 zeigt eine Implementierung, die davon erbt und die Methode ExecuteAsync überschreibt. Diese Methode bringt WebHooks bei jedem empfangenen Ereignis nach erfolgreicher Validierung des hinterlegten Geheimnisses zur Ausführung. Der übergebene String receiver informiert über den Empfänger der Nachricht. Im betrachteten Fall handelt es sich dabei um den GitHub-Receiver. Für diesen kommt der String GitHub zum Einsatz.

Das übergebene Kontextobjekt bietet weitere Informationen, wie zum Beispiel die ID des Abos oder ein aus der Welt von ASP.NET Web API bekanntes HttpRequestMessage-Objekt, das die gesamte Anfrage beschreibt. Die Eigenschaft Actions informiert über die einzelnen Aktionen, die zur Benachrichtigung geführt haben, und die Methode GetDataOrDefault bietet Zugriff auf die vom Verleger veröffentlichten Informationen. Das betrachtete Beispiel nutzt diese Methode, um die erhaltenen Informationen in Form eines JObjects zu erhalten. Stattdessen kann der Entwickler jedoch auch auf eine Klasse zurückgreifen, die die empfangenen Daten stärker typisiert repräsentiert.

Um dem Verleger eine Antwort zukommen zu lassen, kann der Handler bei der Eigenschaft Response des übergebenen Kontextes eine HttpReponseMessage hinterlegen, die die zu retournierende HTTP-basierte Antwort wiederspiegelt. Das gezeigte Beispiel deutet diese Möglichkeit über ein Kommentar an. Wie weiter oben diskutiert, führt das dazu, dass nachgelagerte Handler nicht zur Ausführung kommen.

Der Abonnent kann auch festlegen, dass ein Handler nur für einen bestimmten Receiver zum Einsatz kommen soll. Genauso kann er die Reihenfolge, in der die einzelnen Handler gerufen werden, durch Hinterlegen einer Ordnungszahl, beeinflussen. Hierzu setzt er im Konstruktor der Handler die Eigenschaften Receiver und Order, was in Listing 1 ebenfalls durch zwei Kommentare andeutet.

Listing 1
public class SimpleHandler : WebHookHandler
{
  public SimpleHandler()
  {
    // this.Receiver = "GitHub";
    // this.Order = 1;
  }

  public override Task ExecuteAsync(
    string receiver, WebHookHandlerContext context)
  {
    Debug.WriteLine(receiver);
    Debug.WriteLine(context.Id);
    Debug.WriteLine(context.Request.Method);
    Debug.WriteLine(context.Actions.FirstOrDefault());
    Debug.WriteLine(context.GetDataOrDefault<JObject>());

    // context.Response = ...

    return Task.FromResult<object>(null);
  }
}

Bereitstellung des Abonnenten

Damit der Verleger den Abonnenten benachrichtigen kann, muss dieser über einen öffentlichen URL erreichbar sein. Zum Testen bietet sich eine Bereitstellung über Azure an. Das hat auch den Vorteil, dass sich der Entwickler sehr einfach mit dem Debugger von Visual Studio zum Abonnenten verbinden und somit die durchgeführten Aktionen, wie den Aufruf des WebHookHandlers, nachvollziehen kann. Informationen dazu findet man online.

Lokale sowie domänenbezogene Sicherheitseinstellungen können jedoch verhindern, dass der Entwickler den Debugger mit der Webanwendung in Azure verbindet. Kann der Entwickler diese Einstellungen nicht beeinflussen, sollte er Visual Studio in einer beispielsweise in Azure gehosteten virtuellen Maschine nutzen.

Abonnent bei GitHub registrieren

Um den Abonnenten bei einem GitHub Repository zu registrieren, meldet sich der Entwickler bei GitHub an und ruft anschließend die Einstellungen des gewünschten Repositories auf (Abb. 1). Auf der Einstellungsseite „Webhooks & services“ (Abb. 2) fügt er den Abonnenten hinzu. Dazu hinterlegt er den URL des für den Abonnenten eingerichteten Receivers. Dieser gestaltet sich wie folgt:

http://<host>/api/webhooks/incoming/<receiver>/<id>

Für den GitHub-Receiver wird die Bezeichnung GitHub in den URL aufgenommen. Das letzte Segment mit der ID ist optional und kommt lediglich bei benannten Abos zum Einsatz.

Neben dem URL legt der Entwickler beim Registrieren des Abonnenten auch fest, in welcher Form er Informationen erhalten soll. Im gezeigten Fall fällt die Entscheidung auf JSON. Daneben legt der Entwickler das zu nutzende Geheimnis fest. Zusätzlich kann er festlegen, über welche Ereignisse er informiert werden möchte (aus Platzgründen nicht dargestellt).

Abb. 1: Link zu den Einstellungen bei GitHub

Abb. 1: Link zu den Einstellungen bei GitHub

Abb. 2: Einstellungsseite für WebHooks bei GitHub

Abb. 2: Einstellungsseite für WebHooks bei GitHub

Zum Testen des WebHooks ist nun eine Aktion im GitHub Repository auszulösen. Beispielsweise könnte der Entwickler eine Datei, wie zum Beispiel die Datei readme.md, online editieren und einchecken. Daraufhin sollte GitHub den Abonnenten benachrichtigen. Informationen über die durchgeführten Benachrichtigungen finden sich im besprochenen Dialog „Webhooks & services“ in den GitHub-Einstellungen (Abb. 3). Hinter den Zeilen, die die einzelnen Benachrichtigungen widerspiegeln, finden sich weitere Informationen dazu. Hierzu gehören die übersendeten Informationen samt Kopfzeilen und Nutzdaten sowie die Antwort des Abonnenten, aber auch die Möglichkeit, die Nachricht erneut zu versenden.

Abb. 3: Durchgeführte Benachrichtigungen

Abb. 3: Durchgeführte Benachrichtigungen

Verleger bereitstellen

Um einen Verleger zu implementieren, richtet der Entwickler eine ASP.NET-basierte Webanwendung mit den Frameworks ASP.NET Web API und ASP.NET MVC ein. Da WebHooks davon ausgeht, dass Benutzer beim System registriert sind, empfiehlt sich zum Testen die Visual-Studio-Projektvorlage unter Verwendung eigener Benutzerkonten zur Authentifizierung. Um in den Genuss von ASP.NET WebHooks zu kommen, sind zusätzlich die folgenden NuGet-Pakete einzubinden:

  • Microsoft.AspNet.WebHooks.Custom.Api
  • Microsoft.AspNet.WebHooks.Custom.Mvc
  • Microsoft.AspNet.WebHooks.Custom.AzureStorage

Diese Pakete bieten unter anderem Erweiterungen für ASP.NET Web API und ASP.NET MVC sowie eine Komponente zum Persistieren von Aboinformationen in einem Azure-Storage-Konto. Die Erweiterungen für ASP.NET Web API, die auch Services zum Verwalten von Abonnenten aufweisen, sind im Rahmen der Konfiguration zu registrieren. Dasselbe gilt für die Komponente zum Persistieren von Aboinformationen:

config.InitializeCustomWebHooks();
config.InitializeCustomWebHooksAzureStorage();
config.InitializeCustomWebHooksApis();

Bei Einsatz der von Visual Studio gebotenen Projektvorlage empfiehlt sich hierzu die Datei App_Start/WebApiConfig.cs. Die Verbindungszeichenfolge für das Azure-Storage-Konto ist in der web.config unter dem Schlüssel MS_AzureStoreConnectionString einzutragen. Da befindet sich auch die von der Projektvorlage eingerichtete Verbindungszeichenfolge DefaultConnection, die ASP.NET Identity zum Verwalten von Benutzerkonten nutzt:

<connectionStrings>
  <add name="DefaultConnection" 
             connectionString="[…]" 
             providerName="System.Data.SqlClient" />
  <add name="MS_AzureStoreConnectionString" 
             connectionString="[…]" />
</connectionStrings>

Authentifizierung von Benutzern

Wie oben erwähnt, verlangt ASP.NET WebHooks, dass beim Registrieren eines Abonnenten sowie beim Auslösen eines Ereignisses ein Benutzer beim System angemeldet ist. Dazu kommt, dass WebHooks nur Abonnenten benachrichtigt, die vom aktuellen Benutzer registriert wurden. Deswegen gehen die nachfolgenden Beschreibungen davon aus, dass ASP.NET Identity zum Verwalten von Benutzerkonten zum Einsatz kommt. Die Projektvorlage von Visual Studio richtet dazu standardmäßig Seiten zum Registrieren und Anmelden von Benutzern ein. Zusätzlich aktiviert sie die Cookie-Middleware, die Informationen über den authentifizierten Benutzer in einem Cookie speichert.

Um Abonnenten via Web-APIs registrieren zu können, bedarf es auch eines Authentifizierungsverfahrens, das ohne interaktive Anmeldeseite auskommt. Im hier betrachteten Beispiel kommt dazu das weit verbreitete Verfahren HTTP BASIC zum Einsatz, das eine Übermittlung von „Benutzername“ und „Passwort“ in einen Kopfzeileneintrag vorsieht. Da ASP.NET Web API hierzu keine direkte Unterstützung bietet, stützen sich die nachfolgenden Ausführungen auf eine einfache Implementierung des Autors, die sich auf GitHub im Namensraum owin.security.basic findet. Diese bietet eine Methode UseHttpBasic zum Registrieren einer entsprechenden Middleware. Listing 2 zeigt die Nutzung dieser Methode innerhalb der Klasse Startup, die sich bei Nutzung der erwähnten Projektvorlage in der Datei App_Start/Startup.Auth.cs wiederfindet. Zum Konfigurieren der Middleware nimmt sie ein Objekt des Typs HttpBasicAuthenticationOptions entgegen. Die Eigenschaft ValidateCredentials erhält einen Lambda-Ausdruck, der den aktuellen Benutzer anhand seines Benutzernamens und Passworts authentifiziert. Dazu delegiert dieser an den UserManager von ASP.NET Identity.

Listing 2
[…]
app.UseHttpBasic(new HttpBasicAuthenticationOptions
  {
    AuthenticationMode = AuthenticationMode.Active,
    ValidateCredentials = (userName, password) => {
      var ctx = HttpContext.Current.GetOwinContext();
      var userManager = ctx.GetUserManager<ApplicationUserManager>();
      var user = userManager.Find(userName, password);
      return user != null;
    }
});
[…]

Umgang mit Ereignissen

Verleger veröffentlichen Informationen über die unterstützten Ereignisse über Implementierungen des Interface IWebHookFilterProvider. Beim Start der Anwendung begibt sich ASP.NET Web Hooks auf die Suche nach dieser Klasse und ruft ihre Methode GetFiltersAsync auf. Diese liefert per Definition eine Beschreibung der möglichen Ereignisse. Ein Beispiel dafür findet sich in Listing 3, das über die Ereignisse statusUpdated sowie error informiert.

Listing 3
public class MyFilterProvider : IWebHookFilterProvider
{
  private readonly Collection<WebHookFilter> filters = 
    new Collection<WebHookFilter>
  {
    new WebHookFilter { 
      Name = "statusUpdated", 
        Description = "there's a new status"
    },
    new WebHookFilter { 
      Name = "error", 
        Description = "there was an error"
    }
  };

  public Task<Collection<WebHookFilter>> GetFiltersAsync()
  {
    return Task.FromResult(this.filters);
  }
}

Abonnenten können sich für sämtliche oder nur für bestimmte dieser Ereignisse anmelden. Um ein Ereignis auszulösen, nutzt der Verleger in einem MVC-Controller oder einem Web-API-Controller die Erweiterungsmethode NotifyAsync:

var result = await this.NotifyAsync(
  "statusUpdated", 
    new { Status = "information available", Date = DateTime.Now });

Diese Methode erhält den Namen des auszulösenden Ereignisses sowie ein Objekt mit Informationen dazu. Diese übersendet ASP.NET WebHooks an die Abonnenten. Das Ergebnis dieser Methode spiegelt die Anzahl der benachrichtigen Abonnenten wider. Dabei ist zu beachten, dass die Erweiterungsmethode NotifyAsync nur genutzt werden kann, wenn der aktuelle Benutzer beim System angemeldet ist.

Abonnenten für eigenen Verleger

Um einen Abonnenten für den Verleger bereitzustellen, ist das NuGet-Paket Microsoft.AspNet.WebHooks.Receivers.Custom in eine ASP.NET-Anwendung einzubinden. Der darin zu findende Receiver ist bei der Konfiguration von ASP.NET Web API (zum Beispiel in der Datei App_Start/WebApiConfig.cs) zu registrieren:

config.InitializeReceiveCustomWebHooks();

Darüber hinaus ist, wie bei der Nutzung des GitHub-Receivers, ein Geheimnis zu konfigurieren. Dieses bezieht ASP.NET WebHooks standardmäßig über die Konfigurationseinstellung MS_WebHookReceiverSecret_Custom in der Datei web.config:

<appSettings>
  <add key="MS_WebHookReceiverSecret_Custom" value="[…]" />
</appSettings>

Um auf Benachrichtigungen reagieren zu können, ist dem Abonnenten mindestens ein WebHookHandler zu spendieren. Dieser gestaltet sich beispielsweise wie in Listing 1.

Abonnent registrieren

Um den Abonnenten beim Verleger zu registrieren, kann der Entwickler das von ASP.NET WebHooks beim Verleger eingerichtete Web-API nutzen. Listing 4 demonstriert das unter Verwendung eines HttpClients. Dieser erhält eine Authorization-Kopfzeile, die einen Benutzernamen und ein dazugehöriges Passwort aufweist. Entsprechend den Vorgaben von HTTP BASIC sind diese Informationen durch einen Doppelpunkt zu trennen und mittels Base64 zu kodieren. Dabei unterstützt die Methode ToBase64 (Listing 5).

Die übersendeten Nutzdaten beinhalten den URL des Abonnenten, der sich beim Einsatz von benutzerdefinierten Verlegern am Muster http:///api/webhooks/incoming/custom/ orientiert.

Wie schon beim Beispiel zu GitHub handelt es sich bei der ID auch hier um eine optionale Angabe. Zur Vereinfachung kommt beim betrachteten Beispiel dieselbe Webanwendung als Verleger und Abonnent zum Einsatz. Aus diesem Grund stützen sich die Adresse des Verlegers und die des Abonnenten auf demselben Host ab. Neben dem URL des Abonnenten übersendet Listing 4 auch das zu nutzende Geheimnis sowie eine Beschreibung für das Abo.

Listing 4
var client = new HttpClient();

var credentials = ToBase64("me@office.com", "P@ssw0rd");
client.DefaultRequestHeaders.Authorization = 
  new AuthenticationHeaderValue("Basic", credentials);

var url = "http://localhost:8798/api/webhooks/registrations";

var body = new
{
  WebHookUri = "http://localhost:8798/api/webhooks/incoming/custom",
  Secret = "1234567890abcdefghijklmnopqrstuvwxyz",
  Description = "Demo-Abbo"
};

var response = await client.PostAsJsonAsync(url, body);

var code = response.StatusCode;
Listing 5
private string ToBase64(string userName, string password)
{
  var bytes = Encoding.UTF8.GetBytes(
    userName + ":" + password);
  return Convert.ToBase64String(bytes);
}

Um die Implementierung zu testen, meldet sich der Entwickler nach dem Registrieren des Abonnenten über ein Benutzerkonto beim Verleger an. Anschließend bringt er die oben beschriebene Erweiterungsmethode NotifyAsync über einen Controller zur Ausführung. Dies sollte zur Benachrichtigung des Abonnenten führen. Dabei ist darauf zu achten, dass der Benutzer, der das Ereignis auslöst, der Benutzer sein muss, der auch den Abonnenten registriert hat.

Informationen über die durchgeführten Aktionen veröffentlicht ASP.NET WebHooks standardmäßig über System.Diagnostics. Somit finden sie sich beim Debuggen im Ausgabefenster von Visual Studio.

Fazit und Ausblick

Mit ASP.NET WebHooks steht künftig ein Framework zur einfachen Realisierung von Publish-/Subscribe-Szenarien via HTTP zur Verfügung. Somit entlastet es das Entwicklungsteam bei der Implementierung von Infrastrukturcode. Dazu zählt das Anmelden und Persistieren von Abonnenten sowie deren Benachrichtigung. Das zugrunde liegende Design erlaubt ein Austauschen einzelner Komponenten. Auf diese Weise kann das Entwicklungsteam beispielsweise eigene Lösungen zum Persistieren von Abonnenten oder zum Ermitteln von Konfigurationsinformationen einsetzen.

Interessant erscheint auch die Möglichkeit, ASP.NET WebHooks mit Nachrichtenwarteschlangen zu verbinden. Abonnenten können so Benachrichtigungen zwischenspeichern und asynchron abarbeiten. Für solche Szenarien sieht das Framework mit der Basisklasse WebHookQueueHandler derzeit eine grundlege Unterstützung vor.

Auch wenn ASP.NET WebHooks schon in der aktuell vorliegenden Betaversion den Umgang mit HTTP-basierten Benachrichtigungen stark vereinfacht, muss man sich vor Augen halten, dass es noch am Anfang steht. So ist beispielsweise darauf zu hoffen, dass künftige Versionen Unterstützung für weitere Datenquellen bieten. Darüber hinaus wäre eine direkte Unterstützung einzelner Nachrichtenwarteschlagen wünschenswert.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -