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
GetEndpointAttribute<T> in EndpointHttpContextExtensions.cs #37425
Comments
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:
|
Triage: this seems like a fair API suggestion. Marking it for review. |
|
API review: 👍🏽 all the points @JamesNK raises. It's a bit difficult to reason about what to do when + 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
+ } |
Thanks for the great feedback :) I originally figured a null return would probably be appropriate since that's the behaivor now when you fetch 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 If the endpoint doesn't exist at all, I'd think it make sense to follow Also considering |
Thanks for contacting us. We're moving this issue to the |
@halter73 Thoughts on closing this out? We were pretty lukewarm about this feature when we last discussed it and I don't think the scenario is super motivating given the existing shorthands that are available. |
The Endpoint extension idea is tempting. |
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 fromHttpContext
, 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>
andGetEndpointAttributes<T>
inEndpointHttpContextExtensions.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>
)The text was updated successfully, but these errors were encountered: