Erweiterte Möglichkeiten mit Web API (Teil 5)
Kommentare

Handler mit HttpClient
Handler können auch clientseitig eingesetzt werden. In diesem Fall ist jedoch nicht von DelegatingHandler, sondern von MessageProcessingHandler abzuleiten (Listing 13). Zusätzlich

Handler mit HttpClient

Handler können auch clientseitig eingesetzt werden. In diesem Fall ist jedoch nicht von DelegatingHandler, sondern von MessageProcessingHandler abzuleiten (Listing 13). Zusätzlich müssen die Methoden ProcessRequest und ProcessResponse aufgerufen werden. Wie die Namen schon vermuten lassen, ruft der HttpClient die Methode ProcessRequest auf, bevor er eine Anfrage sendet, und ProcessResponse, nachdem er Antwort empfangen hat.

Listing 13
class LoggingMessageHandler : MessageProcessingHandler
{
    public LoggingMessageHandler() : base() { }
 
    public LoggingMessageHandler(MessageProcessingHandler h) : base(h) { }
 
    protected override HttpRequestMessage ProcessRequest(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
    {
        Debug.WriteLine("Request: " + request.RequestUri.ToString());
        return request;
 
    }
 
    protected override HttpResponseMessage ProcessResponse(HttpResponseMessage response, System.Threading.CancellationToken cancellationToken)
    {
        Debug.WriteLine("Response: " + response.StatusCode);
        return response;
    }
}  

Ein weiterer Unterschied zum DelegatingHandler besteht darin, dass beim Einsatz von MessageProcessingHandler manuell eine Aufrufkette zu erzeugen ist – serverseitig kümmert sich das API darum. Am Ende dieser Kette muss sich eine Instanz von HttpClientHandler befinden. Dieser Handler kümmert sich um das Verarbeiten der empfangenen Nachricht. Listing 14 demonstriert dies, indem es eine zweiteilige Kette erzeugt, bestehend aus dem zuvor gezeigten LoggingMessageHandler und dem obligatorischen HttpClientHandler. Der erste Knoten dieser Kette wird anschließend an den Konstruktor von HttpClient übergeben.

Listing 14
// Handler instanziieren und verketten
var handler = new LoggingMessageHandler
{
    InnerHandler = new HttpClientHandler()
};
 
// Client erzeugen
var client = new HttpClient(handler);
 

var url = "http://localhost:1283/api/Hotels";
 
// Daten anfordern
client.GetAsync(url).ContinueWith(getTask =>
{
     getTask.Result.Content.ReadAsAsync>().ContinueWith(readTask =>
    {
        var hotels = readTask.Result;
        foreach (var hotel in hotels)
        {
            Console.WriteLine(hotel.Bezeichnung);
        }
 
    });
});  
Services mit Self Hosting

Web-API-basierte Services müssen nicht zwangsweise innerhalb von IIS laufen. Bei Bedarf kann der Entwickler sie auch in einer benutzerdefinierten Anwendung, zum Beispiel einer Kommandozeilenapplikation oder einem Windows-Dienst, zur Ausführung bringen. Hierbei ist von Self-Hosting die Rede. Die dazu benötigten Assemblies System.Net.Http, System.Web.Extensions, System.Web.Http, System.Web.Http.Common und System.Web.Http.SelfHost können unter anderem über ein zu diesem Zwecke bereitgestelltes NuGet-Package mit dem Namen ASP.NET Web API Self Host (Beta) bezogen werden. Wie Listing 15 zeigt, ist dazu lediglich eine Instanz von HttpSelfHostConfiguration zu erzeugen. Diese kann mit Konfigurationsinformationen, wie zum Beispiel Routen, versehen werden. IncludeErrorDetailPolicy legt fest, ob Fehlermeldungen zum Client übertragen werden sollen. Um potenzielle Angreifer nicht mit Informationen zu versorgen, sollte diese Einstellung zumindest im Produktivbetrieb deaktiviert (Option Never) oder auf LocalOnly gesetzt werden. Transfermode gibt an, ob die empfangenen und/oder gesendeten Daten gestreamt werden sollen. Die Standardeinstellung ist Buffered, was bedeutet, dass eine Nachricht erst Verwendung findet, nachdem sie vollkommen empfangen wurde. Alternativ dazu legt StreamedRequest fest, dass die Anfrage gestreamt wird. StreamedResponse veranlasst ein Streamen der Antwort, und Streamed ist die Kombination aus diesen beiden Optionen. Damit Streaming funktioniert, müssen der Übergabeparameter und/oder der Rückgabewert aus einem einzigen Stream bestehen. MaxReceivedMessageSize legt die maximale empfangbare Nachrichtengröße fest; MaxBufferSize hingegen die maximale Größe jenes Nachrichtenteils, der gepuffert werden kann. Im Fall von Streaming kann dieser Wert kleiner als jener von MaxReceivedMessageSize sein. Ansonsten müssen beide Parameter dieselbe Größe aufweisen.

Nachdem eine HttpSelfHostConfiguration konfiguriert wurde, ist sie mittels OpenAsync zu starten. Ab diesem Zeitpunkt bietet sie die im aktuellen Projekt verfügbaren Services über den im Konstruktor definierten URL an. Soll die HttpSelfHostConfiguration auch Services aus referenzierten Projekten anbieten, sind diese in der vorliegenden BETA 1 vor dem Aufruf von OpenAsync manuell in den Speicher zu laden. Dazu genügt die Ermittlung der entsprechenden Typen mittels typeof (vgl. Listing 15).

Listing 15
var config = new HttpSelfHostConfiguration("http://localhost:8080");
 
// HACK für MVC 4 BETA, Controller in Speicher laden ... 
Type hc = typeof(HotelsController);
Type bc = typeof(BuchungenController);
 
config.Routes.MapHttpRoute(
    "API Default", "api/{controller}/{id}", 
    new { id = RouteParameter.Optional });
 
config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
config.TransferMode = System.ServiceModel.TransferMode.Buffered; 
                          // Streamed, StreamedRequest, StreamedResponse
config.MaxReceivedMessageSize = 1000000;
config.MaxBufferSize = 1000000;
 
using (HttpSelfHostServer server = new HttpSelfHostServer(config)) { 
    server.OpenAsync().Wait(); 
    Console.WriteLine("Press Enter to quit."); 
    Console.ReadLine();   

Das erwartet Sie auf den kommenden Seiten:

  • SSL für Web API ohne IIS
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -