Re: HTTP binding options

Sanjiva, 

we can change option 5 (and option 4, I guess) to say that putting stuff
in the URI is only supported when the input message conforms to the
style elaborated in the RPC rules (possibly with the further restriction
that all parameters have simple types). It doesn't mean the style
bleeding into the binding, it means that the HTTP binding constrains the
*input messages* in a way similar to the RPC style. 8-)

With this change, I support option 5.

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Thu, 2003-11-06 at 08:57, 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 Wednesday, 12 November 2003 14:56:24 UTC