Add easier way to name endpoints for easier link generation

[davidfowl]

Today it's possible to use the LinkGenerator to generate links to arbitrary endpoints but it's a little inconvenient to do this for endpoints that exists outside of MVC because they don't have intrinsic names or route values (like "controller" and "action").

Here's an example of what this looks like this today:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", (LinkGenerator linkGenerator) =>
{
    return linkGenerator.GetPathByName("todos", values: new { id = 13 });
});

app.MapGet("/todos/{id}", (int id) => { }).WithMetadata(new EndpointNameMetadata("todos"));

app.Run();

Some ideas:

• We add an extension method WithName to hide the explict metadata addition.
• Automatically infer some defaults based on route template.
• Automatically infer some defaults based on method name (if not compiler generated).

[javiercn]

I might be saying the same things as you, but here are some thoughts:

• If using a local function, automatically use that name.
• If using a lambda, consider having an attribute [EndpointName] [RouteName] that you can apply to it.
• You can also have a separate overload template, name, action to do this.
• You could default to /todos/{id} as the default name, although it can get ambiguous.
• You could also have your own addressing scheme within the link generator to address the functions that you code-generate at compile time using GetPathByAddress (with appropriate extension methods around it)

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[pranavkm]

@davidfowl please speak to @javiercn if you need something specific for 6.0.

[davidfowl]

Yes I'd like this for .NET 6, it's part of the minimal APIs end to end.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint 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.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[DamianEdwards]

@davidfowl this can be closed now yes?

[davidfowl]

Yep. Closing.