9

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.

| improve this question | |
4

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

| improve this answer | |
  • 2
    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
  • 1
    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
0

Have a look at the guidelines from the Heroku team. Amongst other things such as Etags they suggest a Request-Id in the header. We are looking to implement most of these guidelines where they make sense.

Trace requests with Request-Ids

Include a Request-Id header in each API response, populated with a UUID value. If both the server and client log these values, it will be helpful for tracing and debugging requests.

https://github.com/interagent/http-api-design/blob/master/README.md

| improve this answer | |
  • 1
    problem with custom headers is they can legitimately be stripped out by proxies. In the end, I went with the Pragma header - it's there to provide a mechanism to send back your own custom data, and it shouldn't be stripped by proxies by default, unless an infrastructure bod explicitly sets it up to be. – Andras Zoltan Dec 12 '14 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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