Sean Landis wrote:
The nature of the data is
a clientId and a callId. These are going to be used for governance and
should be part of every call in our environment. It seemed to me that
since it was not application related, that it ought to be hidden. I'd love
to hear about alternatives though.
Not knowing what data your childId and callId represents, I'd hazard to
say that these parameters relate to state? Or, are these related to
authentication? I'm not sure what "governance" means in this setting.
Sounds like it's a glorified cookie to me.
Not trying to bring another REST war to the list, but I'm not sure that
passing "hidden" values in HTTP headers is very RESTful. Somewhere you
obviously have some code evaluating these data points, which at some
level implies that they are in fact application related. This is for
the exact same reason that passing around cookies (for storing state) is
not RESTful.
The HTTP spec obviously allows unknown non-standard headers to be
passed. But, from a philosophical point of view, the very nature of
this _may_ make your application unRESTful. This is especially true if
these parameters can lead to any change in the Representation.
I guess that's ultimately the question. Can the representation change
based on the values of clientId or callId? Does a previously called
representation create these values and the "application" expects the
client to return them in every call? If so, these parameters should
definitely be passed in the URL instead of a hidden HTTP header.
If alternatively these fields are more for either a) "tracking"
purposes, or _maybe_ b) authentication/authorization purposes, then you
_may_ be OK to include them as non-standard http headers (in terms of
being RESTful).
Remember that for authentication, the HTTP spec has already laid out its
preferred authentication rules, and as such, caching proxies know how to
appropriately cache (or not cache) a representation based on a series of
rules. Obviously, a caching proxy isn't going to know that a custom
header should follow the same types of rules.
Remember too that HTTP really is meant to be stateless, and a RESTful
application therefore does not require the client to store any sort of
state related variable. That's what the name 'callId' seems to imply
(at least, that's what I infer). The only "state" (loosely defined)
that a client should be storing is: a) urls, b) authentication
credentials (basic, digest, etc.).
Of course, if the goal is to not strictly be a RESTful application, then
all bets are off and you can do whatever you want to do. Might as well
wash with SOAP at that point. ;)
Adam
