Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for global conventions on WebApplication #59983

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

captainsafia
Copy link
Member

Implements #59755.

This pull request introduces changes to the WebApplication class and its associated components to support global endpoint conventions.

Changes include:

  • Replaced the internal _dataSources list with GlobalEndpointRouteBuilder and RouteGroupBuilder to create an implicit global route group for all endpoints (src/DefaultBuilder/src/WebApplication.cs).
  • Added a new Conventions property to expose IEndpointConventionBuilder for the application (src/DefaultBuilder/src/WebApplication.cs) that maps to underlying RouteGroupBuilder
  • Added test cases in WebApplicationGlobalConventionTests to verify the application of global conventions on endpoints (src/DefaultBuilder/test/Microsoft.AspNetCore.Tests/WebApplicationGlobalConventionTests.cs).

Wait to review + merge until attached API proposal is reviewed.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically label Jan 21, 2025
}

[Fact]
public async Task ThrowsExceptionOnNonRouteEndpointsAtTopLevel()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@halter73 I realized while working through test cases for this that route groups are only designed to work with RouteEndpoints due to the requirement to be able to concatenate the route prefix to the route when constructing the endpoint. See the comment you left here below.

// Endpoint does not provide a RoutePattern but RouteEndpoint does. So it's impossible to apply a prefix for custom Endpoints.
// Supporting arbitrary Endpoints just to add group metadata would require changing the Endpoint type breaking any real scenario.
if (endpoint is not RouteEndpoint routeEndpoint)
{
throw new NotSupportedException(Resources.FormatMapGroup_CustomEndpointUnsupported(endpoint.GetType()));
}

We have two options at the moment:

  • Leave things as is. The WebApplication will still work with our primary scenarios (Blazor, MVC, SignalR, etc.) but users using custom endpoints will have to use a branched pipeline to register endpoints.
  • Revise the implementation of grouped endpoints to support un-routed endpoints, perhaps by defaulting to an empty prefix + route for all? I haven't evaluated how expensive this would be.

@captainsafia captainsafia added area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc and removed needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically labels Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant