Add IRouteDiagnosticsMetadata

[JamesNK]

Background and Motivation

The Open Telemetry HTTP server semantic conventions records required and optional data to include with metrics measurements. A recommended tag is the route match by the HTTP request. For example, an HTTP request to app.MapGet("product/{id}", () => ...) would have the route product/{id}.

The route is available in ASP.NET Core on the matched endpoint in the RouteEndpoint.RoutePattern. However, HTTP metrics are run in Microsoft.AspNetCore.Hosting. That code doesn't have access to RouteEndpoint, which is in Microsoft.AspNetCore.Routing, because of layering.

Two possible solutions:

• Move RouteEndpoint, RoutePattern, and all its dependencies to Microsoft.AspNetCore.Http.Abstractions and type forward. Then hosting can check if the matched endpoint is a RouteEndpoint and access the route. However, the route pattern is quite a lot of code to move.
• Or, add new diagnostics metadata to Microsoft.AspNetCore.Http.Abstractions. The metadata has a property with a string version of the pattern. Hosting diagnostics can then get the metadata from the endpoint, and use whatever text value is present.

Proposed API

namespace Microsoft.AspNetCore.Http.Metadata;

+ public interface IRouteDiagnosticsMetadata
+ {
+     string Route { get; }
+ }

Usage Examples

if (context.MetricsEnabled)
{
    var route = httpContext.GetEndpoint()?.Metadata.GetMetadata<IRouteDiagnosticsMetadata>()?.Route;

    _metrics.RequestEnd(
        httpContext.Request.Protocol,
        httpContext.Request.Scheme,
        httpContext.Request.Method,
        httpContext.Request.Host,
        route,
        httpContext.Response.StatusCode,
        startTimestamp,
        currentTimestamp);
}

Alternative Designs

See description.

Risks

[ghost]

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.

[halter73]

API Review Note:

• Would we ever consider moving RouteEndpoint and RoutePattern down into Http.Abstractions.dll?
  • RoutePattern might be too big when all we need is the string for stuff like diagnostics and logging.
• Microsoft.AspNetCore.Http.Metadata or Microsoft.AspNetCore.Routing? Let's hide it in Microsoft.AspNetCore.Http.Metadata.
• Can we just have Routing.dll add metadata with the actual RoutePattern? If you have a reference to routing, you can just cast the Endpoint to a RouteEndpoint.
  • var route = ((RouteEndpoint)httpContext.GetEndpoint()).RoutePattern
  • Hosting needs it.
• Do we like the name Route for the property? What about RoutePattern?
  • We don't want to get peoples hopes up that they're getting the actual RoutePattern type.
• What about the IRouteDiagnosticsMetadata type name? There could be a lot of "Diagnostics". Would we add more to it in the future? Probably not.

API Approved!

// Microsoft.AspNetCore.Http.Abstractions.dll

namespace Microsoft.AspNetCore.Http.Metadata;

+ public interface IRouteDiagnosticsMetadata
+ {
+     string Route { get; }
+ }

[amcasey]

@JamesNK was this fixed by #46834?