Re: HTTP binding options

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).

I think I'd prefer doing (3) with a slight change, i.e. that we also
support the PUT/POST analog of "GET binding for operations with
MEP=in-out and with no input body". This amounts to a "POST binding for
operations with MEP=in-out and with no output body". PUT would work as
well, as long as there are no faults.

Anyway, that would seem to satisfy the REST requirements, or at least
that's what I gathered from reading [1].

Roberto

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0059.html

Received on Monday, 10 November 2003 14:49:48 UTC