"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 PrescodReceived on Tuesday, 21 May 2002 07:50:22 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC