Supporting a RESTful service - Should I use Pragma, Cookies, a Custom Header or something else to identify client sessions and transactions?

Question

The problem

We are building an SOA with a RESTful approach to the services. Once the systems are in production we will have many clients consuming the interface including internal and 3rd party systems.

We would like to be able to consume and echo in the response information provided by the client application such as: -

• Session Id - Could be a Java EE session id or anything client specific, this is useful for the support team and debugging client issues to trace them through all our systems.
• Transaction Id - A unique identifier for the request that we can echo back to the client to aid the client in request/response correlation if they invoke the service asynchronously or if we implement an 202 Accepted style long running process.

Potential solutions

So sticking to the RESTful constraints would suggest we need to utilise HTTP to implement this and there are several options we could implement.

• Pragma header - implement extension-pragmas for transaction-id, session-id, etc. This seems like purist of solutions as it utilises a standard HTTP header although I would be concerned it became a dumping ground for everything we can't be bothered to think about properly.
• X-My-Header - custom headers for each field we require. May be stripped by proxies, not core HTTP so feels anti-rest
• In query string or XML/JSON representations - Add the fields to all our resources. Because it's an operational parameter it feels like it should be provided as metadata rather than on a resource.
• Cookies - use Cookie and Set-Cookie to hold custom key-values; useful in the case of session ids as most implementations use cookies already. Would have to re-send every time to support client side correlation which kind of defeats the point of using a cookie.

The answer

Is there any precedent for this? Are we mad? Is there something obvious I am missing in all my research? Does no-one actually care how they will support their services once they are deployed? Should I just shut up and go away?

I'm hoping someone can help.

P.S. sorry if this is a bit of an essay, the advice did say "be specific"....

Answer 1

Oh, this is a pain. I've been there too.

Well, the idea with metadata for transactions, sessions etc. is a good idea. For logging, at least.

The problem is to setup something that is compliant with various corporations policies and SOA infrastructure.

There is a tradeof between best design and maximum interopability in the case of HTTP.

The safe path is to encode the metadata in the message itself. Not very nice, and such a solution ends up looking a bit like SOAP where you have an envelope with headers for all messages.

I ended up using an X-header for information such as transaction id. However, as you mentioned, proxies/b2b-gateways etc. might strip headers, it's not obvious that you can retreive them with all appointed development frameworks, COTS applications etc. So if you do like this, you should avoid make the metadata mandatory to get a solution running - just "nice to have".

Cookies are nothing but pain. They might be annoying or sometimes even useful with browser interaction, but in a SOA scenario, it will be bad idea. Many things can go wrong and it's a pain to debug cross organisations.

I would also avoid using query strings along with POST or PUT data. It's possible according to the HTTP specs. but not when it comes to implementation in random framework.