At this point, we’ve discussed setting up exception handlers as the first step in our middleware pipeline. We’ve reviewed how to redirect HTTP requests to a more secure protocol and we’ve talked about a component to render CSS and other static files that affect the appearance of our application. We’ve even discussed how the application determines where to send the HTTP request and how it checks to ensure the request is authorized. Now, let’s take a moment to examine how the pipeline starts returning a response for the HTTP request.

Before we begin, let’s first talk about the final destination of a request. In an ASP.NET Core application the final destination of an HTTP request is known as an endpoint. Endpoints are blocks of code capable of handling the HTTP request and providing a response. For example, if the request is for the Contact page of a particular site, the endpoint would be the block of code which returns the Contact page as a response.

If the pipeline is not short-circuited, typically the last component in the pipeline is UseEndpoints(). If we think of ASP.NET core routing as being similar to mailing a letter to a friend, we can liken UseRouting() to looking up our friend’s address and UseEndpoints() to actually placing the addressed letter in the mail and having the postal service send it to the correct destination. From a technical perspective, UseEndpoints() calls MapRazorPages() with a lambda expression to register the endpoint, and then executes the selected delegate that matches our HTTP request.

app.UseEndpoints(endpoints =>
{
  // Map Razor pages here
});

Once the appropriate delegate for our HTTP request has been executed, a response is generated. The response travels back through the middleware pipeline traversing each component in reverse order until the response is returned to the user. Since UseEndpoints() begins returning the response, it is important to note that any code placed after UseEndpoints() will only be executed if no endpoint was found to match the request.