GetEndpointAttribute<T> in EndpointHttpContextExtensions.cs

[danleonard-nj]

Is your feature request related to a problem?

Not a problem, just a nice-to-have. It'd be convenient to be able to fetch route attributes directly from HttpContext. I've found it comes up pretty often when working with custom middleware, it's not a long path to get to the metadata from the context itself as it is now, but as there's already extensions to fetch the endpoint itself from HttpContext, it may also be useful to include something like this and maybe another extension to fetch a collection of route attributes.

Describe the solution you'd like

Perhaps something like GetEndpointAttribute<T> and GetEndpointAttributes<T> in EndpointHttpContextExtensions.cs alongside the other endpoint-related extensions.

Additional context

This is the basic idea (minus handling nulls, etc - that'd be handled the same way it is right now in GetEndpoint<T>)

public static T GetEndpointAttribute<T>(this HttpContext httpContext) where T : Attribute
{
  var attribute = httpContext
    .Features
    .Get<IEndpointFeature>()
    .Endpoint
    .Metadata.GetMetadata<T>();
  
  return attribute;
}

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.

[captainsafia]

Triage: this seems like a fair API suggestion. Marking it for review.

[JamesNK]

• What happens if there is no endpoint? Throw an error or return default(T)?
• The name should be GetEndpointMetadata.
• What about getting multiple metadata for a type, e.g. calling into https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.endpointmetadatacollection.getorderedmetadata?view=aspnetcore-6.0#Microsoft_AspNetCore_Http_EndpointMetadataCollection_GetOrderedMetadata__1. GetEndpointOrderedMetadata?
• Concern that this will fill up intellisense for HttpContext?

[pranavkm]

API review:

👍🏽 all the points @JamesNK raises. It's a bit difficult to reason about what to do when GetEndpoint() returns null. A alternative we might consider is to bump the GetMetadata and GetOrderedMetadata to hang off of Endpoint:

+ public static class EndpointExtensions
+ {
+    public T? GetMetadata<T>(this Endpoint endpoint) where T : class
+    public IReadOnlyList<T> GetOrderedMetadata<T>(this Endpoint endpoint) where T : class
+ }

[danleonard-nj]

Thanks for the great feedback :)

I originally figured a null return would probably be appropriate since that's the behaivor now when you fetch Endpoint from HttpContext.

public static Endpoint? GetEndpoint(this HttpContext context)
{
    if (context == null)
    {
        throw new ArgumentNullException(nameof(context));
    }

    return context.Features.Get<IEndpointFeature>()?.Endpoint;
}

Good question on the multiple metadata, hadn't fully considered. Does it muddy things up to return IOrderedEnumerable<T>? That partially addresses the returns - trying to fetch attributes that don't exist on the endpoint would just hand back an empty collection.

If the endpoint doesn't exist at all, I'd think it make sense to follow GetEndpoint and return a null.

Also considering GetEndpoint, it does most of the job, in case adding anything further downstream seems like more trouble than the payoff, that one is definitely handy.