use of http.route for normalized urls in client spans??

[notcool11]

Looking at the http conventions, the usage of http.route is specific to server spans:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/http.md

However, trying to find the right tag to use for a normalized REST like url. When analyzing client spans in aggregate, REST urls like this are a real pain:

/api/endpoint/123/action
/api/endpoint/456/action
/api/endpoint/789/action

On a server span, the http.route would have the normalized value and would look more like this:

/api/endpoint/{id}/action

When all systems are instrumented this is less of an issue, but when making external/vendor calls or calls to internal systems that are not instrumented 😲 having a normalized URL is very helpful. Any help appreciated.

[iNikem]

The problem is exactly the fact that only server knows how/if it normalises urls. Client usually has no such knowledge.

[TylerHelmuth]

Agreed, which would results in having to guess what part of the url to normalize if providing the functionality OOTB.

Since normalizing by guessing sounds pretty hard to get correct, what should be done instead?

[notcool11]

The other side is figuring out what tag to use. As mentioned, the specification only allows for setting http.route on server spans, need direction on what to set for client spans.

The overall problem is the the specification punted on the client Operation, it just sets it to http.method. If a client is calling to a dozen endpoints to the same hostname, there is no good way to differentiate what calls are failing and what are working. Yes, the http.url is set, but for REST based endpoints this is useless.

So, if we have to roll our own normalization solution that is fine. But still need direction on the right tag to use. Thanks.