Re: HTTP binding options

On Mon, 2003-11-10 at 08:51, Sanjiva Weerawarana wrote:
> > I currently favor option 5. SOAP 1.2 includes a SOAP response-only MEP
> > and we ought to support it reasonably, which not the case of option 1,
> > 2, and 3. It is also a matter of enabling Web applications to take
> > advantage of Web Services, without requiring a SOAP stack. True enough,
> > this has to be done with limitations, because of the limitations of HTTP
> > itself. Option (4) can require to use the RPC style at the interface
> > level if necessary. Regarding option 5, the idea of not being able to
> > expose a database of images where each image has its own uri, without
> > using parameters, is simply absurd. HTTP is out there and we better take
> > advantage of it. Finally, I would note that enabling option 5 does
> > affect at all our abstract model. It does affect the way applications
> > can define interfaces since the RPC style must be required in the case
> > of HTTP GET.
> 
> The problem with doing (5) is that it bleeds the value of @style to
> bindings. I think that's pretty bad.

Not at all. (5) requires the use of @style in the interface, but does
not move it or redefine it in the bindings.

> Secondly, I'm not sure that (5) adheres to REST principles. One of the
> motivations for the HTTP binding is to support RESTers .. so if it
> contradicts then its not good. Can we hear from REST proponents? Mark?

My concern here has nothing to do with REST, but with HTTP. We should
take advantage of its functionalities.

Philippe

Received on Monday, 10 November 2003 09:51:42 UTC