Based on what you wrote Adam, it sounds like you would agree that using
hidden parameters in this case doesn't break REST. Now that I've explained
what we are trying to accomplish, can you suggest a more RESTful
approach? We are very interested in being as RESTful as possible.
Sounds like you're creating a custom User-Agent header? Now I
understand what you are getting at with clientId.
If you've got control over the client, then obviously it's possible to
modify the user agent header to provide the kind of versioning
information you described for clientId. But, if your clients are common
browsers, then I think you're probably better using long expiring cookies.
And, with regards to callId, you're definitely talking about "tracking"
(or insert any other fancy term, like "analytics") as I presumed. This
too could use a cookie. Or, you could generate a unique id (serial
number) in the User Agent (again, if you have control of the client).
Or, you can generally follow a user's usage if they are authenticated.
I would tend to avoid custom headers at all costs. It seems too
fragile, but I guess that's just me.
Seems like you can use the standard http headers (User-Agent, Set-Cookie
& Cookie) to do everything you're talking about, which is good in order
to play nice with proxies, caches and/or future HTTP clients.
Adam
p.s. The comment about SOAP was more a joke than anything. Thus the
;). All I was saying is that, with HTTP, you can make whatever type of
application you want. Obviously you know that. REST is, as you say, a
style guide and nothing more.
