Menu
X-headers are fields in the request HTTP header beginning with an X. Put simply. These fields are kind of non-standard or proprietary add-ons to the regular fields in the HTTP header.
Any computer that handles a message is allowed to append its own headers. By convention, if a system wants to add its own custom header, it starts with X-. This is so they can be sure their custom headers don't accidentally take the name of any defined header, current or future.
An HTTP header is a field of an HTTP request or response that passes additional context and metadata about the request or response. For example, a request message can use headers to indicate it's preferred media formats, while a response can use header to indicate the media format of the returned body.
The RequestID uniquely identifies the HTTP request sent from the app to the service and enables the app to correlate requests and responses, in case the app needs to resend a request because of a dropped connection.
When you're operating a webservice that is accessed by clients, it might be difficult to correlate requests (that a client can see) with server logs (that the server can see).
The idea of the X-Request-ID is that a client can create some random ID and pass it to the server. The server then include that ID in every log statement that it creates. If a client receives an error it can include the ID in a bug report, allowing the server operator to look up the corresponding log statements (without having to rely on timestamps, IPs, etc).
As this ID is generated (randomly) by the client it does not contain any sensitive information, and should thus not violate the user's privacy. As a unique ID is created per request it does also not help with tracking users.
Purpose: Idempotency
With an ID that changes for every request, but stays the same in case of a retry of a request, the receiver can ensure the request won't get processed more than once.
This is a quote from some API provider:
All POST, PUT, and PATCH HTTP requests should contain a unique X-Request-Id header which is used to ensure idempotent message processing in case of a retry
If you make it a random string, unique per request, it won't infringe on your privacy, nor enable tracking.
If you want to know more of what idempotency has to offer, read this insightful article.
N.B. As Stefan Kögl comments, this header is not standardized - hence the (deprecated) "X-" prefix.
Your internet is playing up (as usual), so you call up Tellstra and you're waiting on the phone forever......finally you give up and slam the phone down in frustration. (This is a failed call. And there is a record of it in Tellstra's call logs.)
"That's it, I'm calling the Ombudsman!"
But the Obmudsman has thousands of call records to go through (all the failed queries of Tellstra). If you tell them that you called Telstra, and that your call was unsuccessful, that won't be enough: how will the Ombudsman know, from all the call records of Tellstra, which one was yours - so that it can be further investigated??
That's where the X-Request-ID comes in - when ever you call Tellstra, you'd pass on a random number (the X-Request-ID) and this is logged in the Tellstra records. That way, the ombudsman (having access to all records) will be able to find your incoming call to find out what went wrong.
The same applies to http requests - it's an id used to help you (as the back end dev) find out what went wrong when a client issues you with an error or big report.
That's the basic summary of it. Any questions etc. just post a comment and I hope to clear it up.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With