Re: Issue 133, and permitting no body

On Fri, 1 Feb 2002, Mark Nottingham wrote:

>
> On Fri, Feb 01, 2002 at 03:18:03PM -0500, Mark Baker wrote:
> > > I like this! I can see four possibilities (not mutually exclusive);
> > >
> > > 1) GET w/ SOAP envelope serialised in URI, response carries envelope
> > > 2) GET w/o any SOAP envelope, response carries envelope
> > > 3) POST w/ SOAP envelope, 303 See Other, #2
> >
> > Hmm. #2 uses an envelope on a response that presumably isn't a fault.
> > AFAIK, we haven't defined any meaning for this.
>
> Not sure if I see the distinction (maybe I've been out of SOAP-land
> too long); #2 is just a SOAP response to a HTTP GET. The binding
> would have to be defined, yes, but I don't know that this is a
> special kind of response, is it?

As #2 may be a result of #3, in that case you may have a request/multiple
reply MEP. This is the case in the example I gave for #3 in my previous
email. Also, if we have the POST part of #3 implicit, we then have #2 (ie
in the case of a public news feed where no registration is needed, and the
way to call it is described elsewhere)

Also I view #2 as a simple one way message, but not using the usual
direction when transported by HTTP
a->b using POST and a<-b using GET (as seen from a)


> > #3 is ok, but doesn't address issue 133 and the use of GET for
> > side-effect free operations.
>
> I'd characterise #3 as having side effects; it's creating a resource
> that one can get the results of the POST from. Yes, it doesn't fully
> address the issue, but it does mesh nicely with the Web architecture
> IMHO; it allows one to make subsequent requests for representations
> without side effects.

#3 indeed has a side effect, registering a listener -> allowing the event
source (using client poll) to send the event to the newly registered
listener. That's why the use of POST is valid there.

>
>
> > > So, my money is on #2&3. I'd also note that the entail the least
> > > amount of work for the WG.
> >
> > Just to reiterate, I'm not suggesting we go ahead and build a GET
> > binding right now.  My suggestion to allow no body in an envelope
> > was in case we wanted to define a GET binding this way at some
> > later date.
> >
> > As I said earlier, we could just address issue 133 with an
> > explanation of how we only bind to POST, and how the binding
> > respects POST semantics by making proper use of HTTP response
> > codes.
>
> I understand. Actually, I'd like to see the WG enable some limited
> but practical functionality for GET, so that rudimentary caching can
> be realised quickly.
>
> An argument could be made that people will be forced to misuse the
> Web architecture until a GET binding is provided, by using POST to
> make requests with no side effects, thereby meaning that 133 isn't
> addressed by just defining a POST binding. I'm not sure such an
> argument would stick, but it's worth a try ;)
>
>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Friday, 1 February 2002 17:24:53 UTC