Plan to migrate IRouter based implementations onto Endpoint Routing

[rynowak]

tldr; for developers with custom IRouter implementations:

• IRouter is currently not compatible with endpoint routing.
• We will attempt to improve this in 3.0, with new APIs, documentation, or both
• If you are using a custom IRouter implementation in 2.2 we recommend disabling endpoint routing: services.AddMvc(options => options.EnableEndpointRouting = false)

---

Summary

I'm developing a plan to make it possible for folks implementing IRouter based functionality to migrate endpoint routing. This is our future direction for MVC and the stack in general, and we don't want to leave users/frameworks behind.

I'm also lumping in this category custom IActionSelector implementations. IActionSelector is not used in endpoint routing so it's just as relevant/obsolete for new apps.

Over time we're going to evolve in the direction of endpoint routing being the primary experience for the whole stack. I don't expect that we'd ever be able to delete IRouter or remove IRouter support from MVC. We can offer users more options to migrate and try to make it as enticing as possible, but some portion will be left behind; either by our choice not to add a feature they want, or their choice not to adopt new features and concepts.

Analysis

Based on analysis, I've found 3 major types of usages:

1. I want to rewrite the route values (usually localization) - example
2. My route values are in a database (usually a CMS, SimpleCommerce) - example
3. I am implementing a framework (OData) - example

Note that these are roughly in ascending order of 'off-road-ness' - reusing less of our implementation gradually. Most genuine challenges in framework design related to application authors writing extensibility that uses and is used by the framework.

Let's go case by case and look at these...

I want to rewrite the route values

Usually the case for this is that you want to have one set of actions that you 'multiply' (cross-product) across different localized strings that you want to appear in the URL. There's a major pivot here regarding whether you want to localize the 'route values' or just localize the URL template.

In general all of these things 'just work' with application model today. Some users choose to implement this with IRouter because they have done that in the past or it's what seems most obvious to them, but there's no real problem with using application model for this.

My route values in the database

Generally this kind of system works by defining a slug route in the route table that matches all URLs, and then looking up a set of route values in a database using the URL path or part of it as a key.

Example:

var urlSlug = ... do database query...;
RouteData.Values["controller"] = urlSlug.EntityType.RoutingController;
RouteData.Values["action"] = urlSlug.EntityType.RoutingAction;
RouteData.Values["id"] = urlSlug.EntityId;

This requires a slightly more involved solution, because the route templates can't be defined statically, and because we don't provide a simple way to 'run code' to select an MVC action. My assumption here is that this user doesn't want to access the DB once on startup to create the route table, they want to make configuration changes while the app is running.

The key here is that this user is reusing MVC's action selector by rewriting the route values.

---

Here's a proposal:

1. Make it so that an IEndpointSelectorPolicy can be filter where it applies by candidate set. This is for isolation.
2. Register a single endpoint that with a metadata that identifies it as a 'slug' endpoint
3. Write an endpoint selector policy that selects the real/action/endpoint and returns it when it finds the 'slug' endpoint

This has a few drawbacks:

• There is no path to support link generation, but I have yet to see an example of this pattern that includes link generation.
• This does not allow you to reuse HTTP method filtering or other policies. The custom implementation is responsible for handling these concerns.

Another approach would be to rewrite the URL. That might be more straightforward.

I am implementing a framework

Upon further analysis, this case is very similar to the above. The framework registers a route that matches a 'slug', and has a custom implementation that produces an action.

This case has fewer drawbacks because they are not using MVC's action selection.

Next steps

Make it so that an IEndpointSelectorPolicy can be filter where it applies by candidate set. This is for isolation.

We need to do this. This is a nice perf enhancement to IEndpointSelectorPolicy and can unblock a framework like OData migrate. We need to do this in 2.2 so it's not a breaking change.

We should consider further whether URL rewriting is a better solution for most of these scenarios.

I think the timeframe for any other choices we'd consider is 3.0

[rynowak]

/cc @davidfowl @JamesNK

[vincent-163]

Is it possible that Endpoint Routing be implemented as a IRouter itself?
I personally believe that the original IRouter approach is the only approach that covers all cases. Or at least, a linear-time search through a list of routers, where each router is a blackbox that rewrites or accepts a route, is inevitable.
The 'slug' route, or generally any routing that applies to all URLs, apparently does not fit well with Endpoint Routing; Endpoint Routing is like a tree where you traverse from the root and find a leaf, but only one leaf. Even if a url rewriter makes itself an endpoint, it has to travel from the root again, where the endpoint is still on the tree.
Also when there are several URL-rewriting mechanisms in place, there must be an order. You don't want every router that rewrites the URL to restart the routing process from the beginning.

[davidfowl]

URL rewriting isn't routing though, why would use use routing to rewrite the URL? We have a URLRewrite middleware specifically for that purpose. You run that before routing makes the decision on what end point gets selected.

[vincent-163]

I mean the routers that want to supply route values and choose actions, and these may want to do link generation too

[rynowak]

The contract of 'endpoint routing' in 3.0 is to produce an instance of IEndpointFeature and attach it to the http context. https://github.com/aspnet/HttpAbstractions/blob/master/src/Microsoft.AspNetCore.Http.Abstractions/Routing/IEndpointFeature.cs

There can be any number of middleware that participate in this cooperatively. There's no reason why you couldn't write an IRouter-based implementation (it's something I've considered). If there's enough demand for us to ship something like this, it's a possibility, but it won't be our default experience.

---

Link generation is a little more complicated because it's not cooperative - but basically you can choose to implement an 'address scheme' which describes how you find a set of endpoints to attempt to use for link generation.

If you're trying to extend the system, broadly, then maybe the right thing to do is create an 'address scheme' that matches your requirements and implement it.

If you're trying to extend an 'in the box' scheme (like MVC's link generation), the you'll have to replace it and provide an implementation that does what you want.

Generally the kinds of things that lead folks to implement IRouter involve running async code when a request comes in. That's a poor fit for link generation, and it's often ignored, maybe that's ok.

---

If you really do want to implement routing extensibility then the most reasonable path would be to provide us with all of the endpoints, and we will work it out. If this is something that's impossible for your scenarios, then I'd like to learn more.

---

My experience helping others understand how to implement routing from WebAPI2/MVC5 -> current is that generally extenders expect a purpose-built extensibility point to exist for what they are trying to do, and shy away from re implementing anything.

Generally in the routing arena it's going to be the case moving forward that you will need to write code if you want to reprogram routing. This is a philosophical pivot on our part to trade openness for performance and features. We think this is the right thing to do because routing is going to be part of just about every scenario.

If you feel like you're blocked, that's not great and we need to make it better.

[rynowak]

Make it so that an IEndpointSelectorPolicy can be filter where it applies by candidate set. This is for isolation.

Done for 2.2