Re: HTTP binding options

So does this mean you are now advocating option 3 (option 2 only 
supports HTTP POST, as far as I can see)?

Jean-Jacques.

Sanjiva Weerawarana wrote:

> 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:44:54 UTC