W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Re: Issue 133, and permitting no body

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>
Message-ID: <OF14E9B681.5CCAD2CB-ON85256B54.0014B637@pok.ibm.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT