For our REST service I want to send back a unique request ID with every response; useful for debugging internal projects but also for offering support to any third parties who might use the service in the future.
I have decided that I need to use a response header, since not all REST requests need to result in a response body (often lower-level REST APIs take advantage purely of status code and description), but would still need to send back this request ID.
I want to ensure, if possible, that I use an HTTP Response Header that is unlikely to be stripped out by any proxies along the way.
This could be very important since a large number of clients will likely be mobile devices with what is bound to be 'interesting' network topologies between them and our servers.
However, the same services are likely to be marketed to other businesses with their own corporate firewalls/proxies too.
Because of this I've basically chucked out the idea of using a custom response header in favour of a well-known header.
My current winning well-known header would be the ETag
header, but while it's almost right, it's not quite - because an ETag
is for a resource, not a request (i.e. two separate requests for the same resource will legitimately return the same ETag
). Moreover, if I do use that, it'll mean I can't do any entity-tagging for anything else.
Anyone have any better ideas?
Update
The Pragma header, it appears, could be used, but I'm having issues writing to it within the Asp.Net WebAPI. Here's a related question on SO.