Creating routing tables

In Chapter 1, Getting Started with ASP.NET Core, we talked about the OWIN pipeline, explaining that we use middleware to build this pipeline. It turns out that there is an MVC middleware that is responsible for interpreting requests and translating them into controller actions. To do this, we need a routing table.

There is only one routing table, as can be seen in this example from the default Visual Studio template:

app.UseRouting();
app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");
});

What do we see here? The UseEndpoints extension method of IApplicationBuilder has a parameter that is an instance of IEndpointRouteBuilder, which lets us add routes to it. A route essentially comprises the following components:

• A name (default)
• A template pattern ({controller=Home}/{action=Index}/{id?})
• Optional default values for each routing parameter (Home, Index)

Also, we have some defaults:

• If no controller is supplied for the URL, then Home is used as the default.
• If no action is supplied, for any controller, then Index is used as the default.

There are some optional parameters that weren't shown in this example:

• Optional routing parameter constraints
• Optional data tokens
• A route handler
• A route constraints resolver

We will go through all of these in this chapter. This is the default MVC template, and this call is identical to having this:

endpoints.MapDefaultControllerRoute();

As for the actual route, the name is just something that has meaning for us, and it is not used in any way. More interesting is the template, which we will see in a moment.

For the record, if you wish to map only controllers, you should include the following call:

endpoints.MapControllers();

This will not include support for Razor Pages; for that, you need this:

endpoints.MapRazorPages();

Having said this, we can have multiple routes defined:

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");

    endpoints.MapControllerRoute(
        name: "admin",
        pattern: "admin/{controller}/{action=Index}");
});

In this example, we have two routes: the second maps a request starting with admin, and it requires an explicit controller name, as it does not have a default. The action does have one (Index).

Here we've seen how to map requests to resources that do exist. The following section explains what to do when the requested resource does not exist!

Fallback endpoints

To define a fallback route—a route that is matched if no other route matches—we can have a fallback to a page (any relative URL), with or without an area:

endpoints.MapFallbackToPage("/Admin");
endpoints.MapFallbackToAreaPage("/", "Admin");

Alternatively, we can have a fallback page with a file:

endpoints.MapFallbackToFile("index.html");

We can have a controller action, with or without an area:

endpoints.MapFallbackToController("Index", "Home");
endpoints.MapFallbackToAreaController("Index", "Home", "Admin");

Or, finally, we can have a delegate, which receives as its sole parameter the request context (HttpContext), from which you can make a decision:

endpoints.MapFallback(ctx =>
{
    ctx.Response.Redirect("/Login");
    return Task.CompletedTask;
});

Each of these MapFallback* extension methods has an overload that has the first parameter of type string that is called pattern. If this overload is used, the pattern parameter can be used to restrict the fallback to requests that match this pattern. See this, for example:

endpoints.MapFallbackToPage("/spa/{**path:nonfile}", "/Missing");

A fallback route should be the last entry on the endpoints routing table.

Let's now see how we can enhance the route by using special tokens in the route templates.