Re: HTTP binding options

I'd say we support HTTP GET for idempotent operations just fine- 
if you read what Mark said, the idea of the URI being dependent
on the message contents is not a required part of Web architecture.

Even the SOAP Response MEP doesn't go as far as (5) - that has
a no-input requirement. So we're really in virgin territory by
going that far and its at a pretty high price (lots of restrictions
on the input (follow RPC style + simple types only), weirdness of
whether the input is really the input and a pretty complex language
to boot).

Sanjiva.

----- Original Message ----- 
From: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: <www-ws-desc@w3.org>; "David Orchard" <dorchard@bea.com>
Sent: Thursday, November 13, 2003 7:34 PM
Subject: Re: HTTP binding options


> 
> After having read the entire thread, I'm still inclined to go for (at 
> least) option 3).
> 
> It would be interesting to know if the TAG is likely to raise an issue 
> if we don't support HTTP GET (for idempotent operations), like it did 
> for SOAP 1.2.
> 
> David, any (wild) guess?
> 
> JJ.
> 
> Sanjiva Weerawarana wrote:
> 
> > The "HTTP binding table" at the post-meeting lunch came up
> > with the following possible options for the HTTP binding:
> > 
> > option 1:
> >     drop HTTP binding completely
> > 
> > option 2:
> >     define a POST binding only with the natural binding possible:
> >     input becomes POST body and output must be POST response
> > 
> > option 3:
> >     define option 2 +
> >     define GET binding for operations with MEP=in-out and with no
> >     input body (i.e., GET goes to http:address URL) and the output
> >     must be the GET response
> > 
> > option 4:
> >     define option 3 + 
> >     define GET binding for operations with MEP=in-out and @style=rpc
> >     ala the WSDL 1.1 binding, but with rules to move all parameters 
> >     into query parameters. (That is, no URL rewriting ala WSDL 1.1.)
> > 
> > option 5:
> >     define option 4 +
> >     add URL replacement to allow different parts to go in the URL
> >     itself vs. as query params
> > 
> > There was pretty strong sentiment against doing (5). (4) has the
> > negative that the value of operation/@style is bleeding into the
> > binding - which would be unfortunate. (3) is interesting and can
> > be generalized a bit for other MEPs if needed. An interesting twist
> > on (3) could be to allow appending a relative URL to the adresss
> > on a per-operation  basis. That's not without price (inconsistent
> > use of xml:base for relative URLs for one).
> > 
> > My current preference is that we do option (2).
> > 
> > Sanjiva.
> >

Received on Thursday, 13 November 2003 09:11:31 UTC