Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 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.)

share|improve this answer
1  
Yes it is an option. But something feels hacky about an enveloped response like this. Consider a json operation returning a string; now it's returning a type with two members and clients have to do more work to get their data. Not very restful! I have found a header in the spec that might do it, I'm posting an answer... –  Andras Zoltan Jul 25 '12 at 21:38
    
Actually, no I haven't, looks like I misinterpreted the spec's definition of 'message-header' as being a specific header and not a BNF rule. Hmmm... –  Andras Zoltan Jul 25 '12 at 21:49
    
In all of my projects I use structured data in the body, never a plain string, because in the future I often need to add new data along with it. JSON is a standard approach and jQuery will automatically make the response body a JS object when returning from AJAX calls. You can also wrap all of your calls/responses in your own functions to handle the structure consistently. –  Matt S Jul 26 '12 at 16:14
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.