Re: Issue 133, and permitting no body

Henrik,

> By taking out the SOAP body as a means of indicating that a SOAP message
> is safe and idempotent, you seem to propose that the body inherently is
> unsafe. I don't think this is necessarily the case - as has been
> discussed, a query is often safe and idempotent and seems to fit nicely
> within a SOAP body.

I agree, and I don't mean to suggest that it's inherently unsafe.  It's
just that requiring a SOAP body in all cases is sure to guarantee that
some developers and users will use it to make GET mean something other
than GET.

Also, I'm not a fan of queries in GET bodies.  IMO, each query should be
uniformly identifiable, and to that means making the query part of the
URI.

For example, if the query were done like this;

GET /query HTTP/1.1
Host: example.org

name=mark&location=ottawa

Then http://example.org/query has no uniform meaning.  It's basically
equivalent to http://example.org/rpc.

I'm not suggesting that *all* queries are inappropriate in a body
(though it's certainly possible and I'd welcome any examples), only
that if there is a line to be drawn, it's unclear where it should be
drawn.  IMO, we can best avoid issues arising from developers and users
crossing that line by not going there at all.

> Being able to serialize such a SOAP message in a URI seems like a good
> thing and if so the mapping to HTTP GET is straight forward.

If the SOAP message was a query, then I can see *some* value in this
since the query becomes identifiable.  But then we'd have to decide what
happened to the headers.  For example, is GET on a urlencoded SOAP
message with a mustUnderstand header equivalent to M-GET?  I don't
believe it should be.  It would mean that a given resource would have
different URIs depending upon the headers used to access it.

In this case, I might suggest something like urlencoding the SOAP query
body, and carrying the SOAP headers in the GET body.  But that also
requires permitting an envelope with no body. 8-)

> Rather than
> removing the body, however, one could potentially provide a schema for
> the body that any safe and idempotent SOAP message type could derive
> from.

I figured it would be cleaner to remove the body entirely, but if that
causes problems elsewhere, yes, this would be a fine solution.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 1 February 2002 08:55:33 UTC