Servers in ASP.NET Core

As mentioned in a previous post, REST requires the implementation of a specific set of constraints. The Client-Server constraint is probably the most foundational and enforces a separation between the client and the server.

This post is part of a series on Implementing REST in ASP.NET Core

Some of the many great features of ASP.NET Core are web servers which include Kestrel, a blazingly fast; cross platform HTTP server based on libuv and WebListener, a Windows-only HTTP server based on http.sys.

In ASP.NET Core, an application runs with an in-process HTTP server implementation inside a web host. Here is the bare minimum that is needed to bootstrap a server (in this case Kestrel) for serving a simple response to satisfy the Client-Server constraint:

var host = new WebHostBuilder()  
    .UseKestrel()
    .Configure(app => 
        app.Run(async context =>
            await context.Response.WriteAsync("Hello world!")))
    .Build();
host.Run();  

The WebHostBuilder follows the builder pattern to create a web application host and contains methods for defining the web server (in this case UseKestrel) as well as the Configure method which houses the start-up logic.

Custom servers

Extensibility is key in ASP.NET Core, which is really great because it means you can create your own components for the framework and use them instead of the built-in ones.

Creating your own custom server is pretty straight forward, just implement the IServer interface.

public interface IServer : IDisposable  
{
    IFeatureCollection Features { get; }
    void Start<TContext>(IHttpApplication<TContext> application);
}

Depending on the implementation, it can be either simple or really complex to do. IServer requires a set of features to be implemented. You are free to implement just the features needed by your application, but by a minimum it needs to support  IHttpRequestFeature and IHttpResponseFeature.

This sums up how one can implement REST's Client-Server constraint in ASP.NET Core.