- From: Paul Prescod <paul@prescod.net>
- Date: Tue, 07 May 2002 15:57:30 -0700
- To: www-tag@w3.org
David Orchard wrote: > >... > > The point that my proposal addresses is how to have a re-usable transcoding > between a SOAP HTTP POST binding and a HTTP GET binding, instead of having > each service create it's own transcoding. > > A sample usage scenario that I see is that a user creates a web service and > marks it as "safe". It seems much more likely to me that the use wants to mark a particular *operation* as a safe, rather than an entire web service. It is also unclear to me why the "input" to this process should be a SOAP/HTTP POST binding. Here's what I was expecting: There is an intermediary which maps from, let's say, the MQSeries/SOAP world to the HTTP/SOAP world. It would be able to bidirectionally transcode MQSeries/SOAP<->HTTP/SOAP, selecting the right method based upon something in the message. Ideally, client side SOAP toolkits would have some mechanism for putting the "something" in the message. > .... A tool then automatically generates a SOAP HTTP POST > binding and a GET binding in the WSDL. Their runtime software could be > configured to automatically map the GET invokes into a POST invoke, perhaps > based upon the "safe" attribute in WSDL. The user only had to create one > implementation (the POST) and the user did not have to define the > transcoding algorithm. Why would a user want both a POST and a GET interface to their service? If the GET binding is complete then a GET interface should be sufficient. Paul Prescod
Received on Tuesday, 7 May 2002 18:57:09 UTC