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.
Best Answer
I would use a standardized body and not use the header. For example, every body can be JSON and include an ID field. As long as it's standardized across your platform it's guaranteed to work.
I would not use a custom header because of the risk of it getting stripped. I would not use a standard header because I don't know of one that fits perfectly (e.g. the ETag you mention is used to determine file changes and caching keys.)