Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP bi nding preamble.

You need something that identifies a function call
as being idempotent; so that the code that does
the HTTP binding knows to use GET.

My gut feeling here is that the simple solution is
just to reserve some SOAP method names like

HTTP-GET
HTTP-POST

for these.

-Alex-


On Tue, 19 Feb 2002, Martin Gudgin wrote:

> Seems to me that nothing in our spec precludes someone from defining a GET
> based binding. I don't think our HTTP binding is such a beast. I don't see
> the GET binding as being in the 'minimum required to declare victory' space.
>
> Gudge
>
> ----- Original Message -----
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Martin Gudgin" <marting@develop.com>
> Cc: "Paul Prescod" <paulp@ActiveState.com>; "Williams, Stuart"
> <skw@hplb.hpl.hp.com>; <xml-dist-app@w3.org>
> Sent: Tuesday, February 19, 2002 5:42 PM
> Subject: Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP
> bi nding preamble.
>
>
> >
> > Hi Gudge,
> >
> > On Tue, Feb 19, 2002 at 12:22:35PM -0000, Martin Gudgin wrote:
> > >
> > > It is unclear ( to me at least ) how such a call would differ from
> > > a standard HTTP GET. What would make it SOAP? Just the fact that
> > > the HTTP response would contain an Envelope element? Or the fact
> > > that the Content-Type header of that response would be
> > > application/xml+soap? Or both?
> >
> > Speaking only for myself (there seem to be a number of positions on
> > this issue!), this (both) is what I'd like to see.
> >
> > Why bother? Because if it's not specified, it won't be widely
> > implemented. The 'profiles' (not my term) of SOAP use that get
> > defined early are important. It gives you compatibility with the Web
> > architecture, low-level caching, etc. and is easy to do.
> >
> >
> > > Also, given that the Envelope will *NOT* be used to serialize the
> > > request is it really SOAP, given that the Envelope is a core part
> > > of the spec? Given that the envelope is hierarchical ( it is an
> > > Infoset, after all ) I'm not sure I can see a reasonable way to
> > > encode it into the query string ( although I can see how you might
> > > encode very simple requests into the URI ).
> >
> > I'm not too concerned with 'what is SOAP/is it SOAP' arguments,
> > because SOAP is a pretty slippery concept (is it a messaging
> > framework? an RPC protocol? A substrate of HTTP? a layer? ... ).
> >
> >
> > > Also, it would seem *VERY* problematic to try and use SOAP Headers
> > > in such an example, where are we supposed to put those in a GET? I
> > > understand that idempotent HTTP requests should use GET. But it
> > > seems that some of the things I might want to include in an
> > > idempotent SOAP request might include SOAP headers. Are you
> > > suggesting we define a way to encode SOAP headers as HTTP headers?
> >
> > I'd say no; in the request, they can use features of the underlying
> > protocol, but there is no slot for an envelope (or maybe just
> > headers; see below). Yes, this is a constraint on the use of the
> > binding, but it's useful, and I don't think it breaks SOAP to define
> > it.
> >
> >
> > > Or maybe the query string should just be ?xml='<soap:Envelope....'
> > > in which case perhaps all these problems go away... Is that what
> > > you think we should do?
> >
> > No! There should be an effort to specify how to express section
> > 5-encoded data into a query string; it may even attempt to defined a
> > framework for expressing SOAP headers as HTTP headers (although I'm
> > a bit doubtful about this one).
> >
> > You end up with something with following properties:
> >   - uses GET
> >   - request only allows bodies with section 5 encoding
> >     (which are serialised in the query string)
> >   - all HTTP protocol features are available
> >   - no SOAP headers are possible in the request (but see above)
> >   - response is a normal HTTP/SOAP response
> >
> > I don't know if this is a new binding or a binding feature of the
> > HTTP binding; perhaps it's a feature, since it limits the
> > functionality of the envelope.
> >
> > (I'd put my hand up to do a proposal for this, but I can't prioritise
> > it right now; if there's support for the idea, though, I'll see what
> > I can do.)
> >
> > Cheers,
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >
>

___________________________________________________________________
S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax

Received on Thursday, 21 February 2002 04:56:05 UTC