- From: Paul Prescod <paul@prescod.net>
- Date: Tue, 21 May 2002 04:50:35 -0700
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- CC: "'Tim Bray'" <tbray@textuality.com>, www-tag@w3.org
"Williams, Stuart" wrote: > > Hi Tim, > > Hmmmm... my preference for the 'Content-Location' approach is because it > works regardless of the style of SOAP message in use. > > The proposed URL-encoding approach works for some subset of SOAP messages > that 1) fit the RPC conventions and 2) have only 'simple' parameter values. The content-location approach is not, IMO, sufficient because it does not provide an algorithm that a SOAP intermediary can use to decide whether to use HTTP GET for a particular hop in the message's journey. By the time you get the content-location, it is too late. You already did a POST of something that was logically a GET. You've already confused proxies and other intermediaries. Furthermore, someone writing directly to the service has no way of generating a correct URI on the client side. > We could debate whether this hits a 60-40 or even 80-20 point - but unless > we work on a URL encoding for almost arbitrary XML, there will be resource > identifying SOAP messages that cannot be encoded into a URL. I guess it just depends on how you look at it. My point of view is that the resource identifiers should be chosen such that they fit into a URI. If you are generating resource identifying messages that cannot fit into a "universal resource identifier" then I think you are doing something wrong. A point of departure for the "Web architecture" folks versus of the "SOAP folks" is that I think that every SOAP message should be generated with the web architecture in mind. Paul Prescod
Received on Tuesday, 21 May 2002 07:50:22 UTC