Suggestion for http.route standardization example my-controller/my-action/{id?} to remove all route transformers and constraints also. (? is a constraint, like :string or :int)

? for sure causes another issue. Can execute just my-controller/my-action/ and hit the same route as {controller}/{action}/{id?} . So in this case {id} should not be used.

request: http://example.org/my-controller/my-action
route template: {controller}/{action/{id?}
http.route: my-controller/my-action

request: http://example.org/my-controller/my-action/5
route template: {controller}/{action/{id?}
http.route: my-controller/my-action/{id}

@RassK HTTP conventions don't define any semantics for HTTP route - the value is coming from the HTTP frameworks. Do you think there a better way to describe it than

?

Given it's stable, we won't be able to standardize the format.

@RassK HTTP conventions don't define any semantics for HTTP route - the value is coming from the HTTP frameworks. Do you think there a better way to describe it than

Yes, I see no direct conventions. I'm interpreting it like that: There is a spec for http server span name, and if the http.route must be included (if exists) in the span name, then span naming spec is a constraint to http.route.

https://github.com/open-telemetry/opentelemetry-specification/blob/v1.47.0/specification/trace/api.md#span

The span name concisely identifies the work represented by the Span, for example, an RPC method name, a function name, or the name of a subtask or stage within a larger computation. The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans, rather than individual Span instances while still being human-readable. That is, "get_user" is a reasonable name, while "get_user/314159", where "314159" is a user ID, is not a good name due to its high cardinality. Generality SHOULD be prioritized over human-readability.

This could be seen constraining http.route not to include framework specifics (like ?, :int, :string, :transformer). Since framework specifics does not follow "The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans".

Suggestions

Some help from chatgpt:

Rules:

• Replace dynamic path segments (IDs, UUIDs, slugs, etc.) with {param}.
• Normalize all placeholders to {param} format, regardless of framework (:id, , {id}).
• Omit optional markers (?) — always record the general case.
• Include all parent segments that are part of the matched route.
• MUST NOT include actual values from requests (e.g., /users/314159).

Examples:

• Express /users/:id → /users/{id}
• Django /articles/int:id/edit/ → /articles/{id}/edit
• ASP.NET {controller}/{action}/{id?} (resolved to Users/Get/42) → /users/get/{id}
• Spring Boot /orders/{orderId} → /orders/{orderId}

In the case of a route template like {controller}/{action}/{id?}, I'd personally categorize all 3 parameters as dynamic. I can see how others may consider controller and action static, as there are a finite set of values for most applications.

Some additional detail might leave less room for interpretation. Here is an attempt:

The matched route template for the request. This MUST be low-cardinality and include all static path segments, with dynamic path segments represented with placeholders.

Along with a footnote defining static vs dynamic and examples for common frameworks like @RassK commented:

A static path segment is a part of the route template with a fixed, low-cardinality value. This includes literal strings like /users/ and placeholders that are constrained to a finite, predefined set of values {controller} or {action}.

A dynamic path segment is a placeholder for a value that can have high cardinality and is not constrained to a predefined list like {id}.
<table of examples>

@matt-hensley @RassK makes sense, would you be willing to send a PR? I can close this one.

@lmolkova opened #2734 for consideration

closing in favor of #2734