Re: Issue 133, and permitting no body

Noah, this is one of those "web architecture" issues again.

Encoding a SOAP envelope in a URI is using GET to tunnel that envelope,
and isn't respecting GET semantics (which are "give me a representation
of the resource identified by the Request-URI").

On the other hand, my proposal allows GET semantics to be extended (but
not fundamentally changed) by the meaning of SOAP headers, as they would
be with HTTP headers.  For example, we'd be able to do mandatory GET by
using mustUnderstand.  Or we'd be able to route GET requests with
WS-Routing (or whatever).  The same goes for almost any other header
(except those meant for non-idempotent or unsafe methods) that may be
defined in the future.

Mark's practical concerns about the deployment of GET+body are of course
important to consider before going much further with this.  But
architecturally at least, and for addressing issue 133, this is a very
clean way of designing a GET binding.

> Taking the SOAP body out of the envelope seems to seriously undercut the 
> fundamental semantics of SOAP.

I gave this some thought, and realized that we'd have to explain what it
meant, but I don't see how it would undercut what SOAP is.

>  Encoding the entire envelope in URI lets 
> us do the right thing, which is to have the SOAP envelope affect the 
> semantics of the GET.

Hmm, I'd say that's exactly the wrong thing to do.  We chose to use
HTTP response codes other than 200 with POST because we wanted to ensure
that SOAP did not automatically (i.e. without developer help) affect the
meaning of POST.  Why would we want to mess with GET?

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

Received on Thursday, 31 January 2002 23:21:44 UTC