Adam Taft <adam <at> adamtaft.com> writes: > > 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.
The problem we have is that we have a landscape of web services and clients. We desire to answer questions like: 1) What clients call this service? 2) What client made this call? 3) What clients use what versions of this service? In terms of governance, if we are contemplating a change to a service that affects clients, we want to know who will be affected. The intent of the clientId is that every client will have a unique identifier that will allow us to answer these questions. This id is of no interest to applications. It has no effect on representations. It is a management artifact. Likewise, with the callId, we want to answer questions like: 1) Which client 'invocation' resulted in this web service condition? 2) Given web service X, what was the call chain from client, to WS A, to WS B, ... WS X? Again, this is about management and has no affect on the application. The ultimate intent is to have this information shipped off to a repository web service that can be used to answer the questions. This would be done through a framework on Restlet that developers use. They'd get this capability automatically. Google web service governance for more background. But beware that most of the players are in the WS-* world and a lot of what's being sold is snake oil. That said, there are very useful governance capabilities such as the ones I mention above. We learned that the hard way. > Sounds like it's a glorified cookie to me. Cookies are for servers to place state on clients. That's not what this is about. [...stuff deleted...] > 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). In our case, it would be a. Philosophically I agree with most of what you say Adam. As you point out there are better alternatives to b) than hidden headers. > 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.). Our clients are applications rather than browsers, and have all sorts of state. > 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. ;) Being RESTful for the sake of purity is nonsense. The reality is that problems have to be solved and there are ways that this can be accomplished using, for example, Restlet. I hear: "You can't have client state, you can't track applications, you can't govern your services because you'd be breaking REST style." Assuming there's not a suitable alternative solution, I translate statements like that to: REST style is great for toy applications, but inappropriate for real world problems. Likewise implying it's pure REST or SOAP is unrealistic. In the real world, there are times where bending or breaking some aspects of REST is the right thing to do. I really like the tenor of "RESTful Web Services" on this point. The authors are very pragmatic and describe a scale of RESTfulness (or ROAness, if you will). We have gained many benefits from being as RESTful as as makes sense, yet we have consciously bent the style where we felt it was justified and when we could find no completely RESTful solution. 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.
