Add APIs to make it possible for users of RouteEndpointBuilder to use filters

[davidfowl]

Background and Motivation

In .NET 7 preview 6 we made it possible to run RouteHandlerFilter (name TBD) on all endpoints. That implementation always wraps the RequestDelegate so that all RouteEndpoint(s) will execute filters. We need to make it possible for custom EndpointDataSource to get access to the filter list on the RouteEndpointBuilder.

Proposed API

namespace Microsoft.AspNetCore.Routing;

public static class RouteEndpointBuilder 
{
+    public List<Func<RouteHandlerContext, RouteHandlerFilterDelegate, RouteHandlerFilterDelegate>>? RouteHandlerFilterFactories { get; set; }
}

Usage Examples

It's non-trivial to show real usage. Generally these filters need to be composed around a delegate. For that, they need to be exposed.

Risks

None

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[halter73]

Why not IEnumerable instead of List? This is really just so custom EndpointDataSources can retrieve them, not mutate them, right? I think it’s fine to make this read-only and only let you add to it with the extension methods.

[davidfowl]

It needs to be mutable (this is a builder API). IList would also be fine.

[halter73]

I'm fine with IList. Should we also make it non-nullable?

[davidfowl]

@halter73 not sure, saving on an allocation per route seems worth it 😅. I guess we can use Array.Empty to do that.

[halter73]

API review notes:

• Do we need the setter either?
  • No. A non-settable, non-nullable, generic IList is also used for EndpointBuilder.Metadata so we're matching an existing property on this type.

API Approved!

namespace Microsoft.AspNetCore.Routing;

public sealed class RouteEndpointBuilder : EndpointBuilder
{
+    public IList<Func<RouteHandlerContext, RouteHandlerFilterDelegate, RouteHandlerFilterDelegate>> RouteHandlerFilterFactories { get; }
}