- From: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
- Date: Fri, 1 Feb 2002 22:51:26 -0500
- To: "Mark Baker <distobj" <distobj@acm.org>
- Cc: "xml-dist-app" <xml-dist-app@w3.org>, "ylafon" <ylafon@w3.org>
Mark Baker writes: >> Unfortunately, it is counter to web architecture, >> as GET is the only method that can mean "retrieve". Is GET sent to a servlet that retrieves a stock quote, for example, counter to the Web architecture? In many cases, the parameters on the servlet URI will partially duplicate the fact that this is a "get", and may even parameterize the resource to be accessed (stock name). Why shouldn't SOAP work the same way? If I want to do getStockQuote through SOAP, why isn't it most appropriate to encode the soap-level request in the URI, and bind it to an HTTP GET. It may not be clear why I think this is so important: applications will want to do the same SOAP calls to a variety of endpoints, without being much aware of the binding. getStockQuote bound to HTTP may well be a GET. getStockQuote bound to MQSeries may be very different on the wire. The point is, the application wants a fair degree of transparency in the SOAP envelope, and if applicable the WSDL and or UDDI. Using a different body convention (I.e. eliminating it) doesn't feel right to me at all. >> That appears to assume that the only subject of a >> header can be the body, no? That was not my concern. Headers can talk about most anything, including a message that was sent yesterday (flow control would be an example of this.) They just have to be "understood" at the node doing the processing. Thank you. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Saturday, 2 February 2002 00:05:33 UTC