Should Trace context replace X-Request-Id?


It's common practice for REST APIs to return the `X-Request-Id` header for
correlation purposes (simplifying post mortem support etc.)

Is the updated trace context standard a good candidate to replace this
idiom or is it best to support both headers to separate the external
communication/correlation of a given request and (possibly) internal
distributed tracing needs?

This gets a little harder to reason about in SaaS vendor scenarios as
outlined in the spec. When a relying party might use trace context and wish
to propagate the sample-flag to a vendor API. Ideally it should be
sufficient with a single header/mechanism to both trigger tracing and
correlate requests.

Any advice on this would be helpful!



Received on Friday, 22 April 2022 17:21:18 UTC