Re: Issue 133, and permitting no body

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