Fallback controller route in ASP.NET Web API v2

Question

I'm building an offline web app that uses the path string for client-side URLs.

There are several (attribute-based) routes that map to dedicated controllers for resources, API calls, etc.. For example:

/myapp/api/...
/myapp/resources/...

I then want all requests that do not match one of these patterns to be routed to my bootstrap HTML page, which I currently serve via a dedicated controller. So, for example, the following requests need to end up at the bootstrap HTML page:

/myapp/customers/...
/myapp/orders/...
/myapp/
/myapp/<anything that doesn't start with another controller's route prefix>

I'm using OWIN, so theoretically I could probably do this with a custom "fallback" handler of some kind. However, I value the functionality that I get for free with the Web API framework.

I should also mention that Web API is already registered under an OWIN-mapped subpath of "/myapp", so that first part of the path will not be seen in the Web API routes. Also, I would like to keep using attribute-based routing if possible, for readability.

The solution I'm envisioning is something like this:

using Microsoft.Owin;
using Owin;
using System;
using System.Web.Http;

[assembly: OwinStartup(typeof(MyApp.Startup))]

namespace MyApp
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.Map("/myapp", myApp =>
            {
                var configuration = new HttpConfiguration();
                configuration.MapHttpAttributeRoutes();
                configuration.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
                myApp.UseWebApi(configuration);
            });
        }
    }

    [RoutePrefix("api")]
    public class MyApiController : ApiController
    {
        [HttpGet, Route("")] // GET: myapp/api
        public string Api() { return "api"; }
    }

    [RoutePrefix("resources")]
    public class ResourcesController : ApiController
    {
        [HttpGet, Route("")] // GET: myapp/resources
        public string Resources() { return "resources"; }
    }

    [RoutePrefix("")]
    public class BootstrapController : ApiController
    {
        [HttpGet, Route("{subpath:regex(^.*$)?}", // GET: myapp/...
            Name = "BootstrapPage", Order = Int32.MaxValue)]
        public string Index(string subpath = "") { return "bootstrap"; }
    }
}

There are two problems with this setup:

1. A request for /myapp/api or /myapp/resources fails with a 500 error because there are multiple matching controller types. I know that routes can be given a priority within a controller, and I guess I was hoping that the route priority would also hold across different controllers. But that was admittedly a shot in the dark.
2. Requests for myapp/customers/ and myapp/orders/today fail with a 404 error, so apparently my route for BootstrapController.Index() is not even working correctly.

The only request that works is /myapp, which correctly returns "bootstrap" with a 200 OK.

I don't know enough about how Web API works to be able to solve this problem. Hopefully someone here can help!

Answer 1

After some more research-guided trial-and-error, I figured out a solution. It doesn't allow me to use attribute-based routing on the BootstrapController, which is not a big deal since it's a special case.

Here are the necessary changes:

app.Map("/myapp", myApp =>
{
    var configuration = new HttpConfiguration();
    configuration.MapHttpAttributeRoutes();
    configuration.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;

    configuration.Routes.MapHttpRoute(
        name: "BootstrapPage",
        routeTemplate: "{*subpath}",
        defaults: new { controller = "Bootstrap", action = "Index", subpath = RouteParameter.Optional });

    myApp.UseWebApi(configuration);
});

The BootstrapController also needs to be rewritten without routing attributes:

public class BootstrapController : ApiController
{
    [HttpGet]
    public string Index() { return "bootstrap"; }
}

It's always obvious in hindsight. :P What I didn't realize was that the "multiple matching routes" problem could be circumvented by using the routing table in combination with attribute-based routes. Then it was just a matter of figuring out how to make the route entry match a subpath of any depth.