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.