Re: HTTP binding for WSDL 1.2

On Thu, 2003-05-29 at 16:40, Mark Baker wrote:
> > As you said, application protocols are not transport protocols and the
> > current HTTP binding proposal doesn't give you the right to misuse HTTP
> > as defined in the RFC.  A WSDL operation must always comply with the
> > constraints of the application protocol method. When an application uses
> > HTTP POST for an GET-like operation, it looses the idempotent property
> > of the HTTP GET method but doesn't infringe the rules of HTTP POST
> > itself (as far as I know). imho, we should provide guidelines on
> > when/how to use HTTP GET/POST, and SOAP over HTTP GET/POST.
> 
> That's great, but I think the easiest way to enforce that is to remove
> the notion of the operation being different than the verb in the 'type=
> "application"' case. 

I doubt that it would be enough in order to enforce appropriate use of
the application transport. People have been able to mess up with the use
of HTTP methods without the help of WSDL, and will continue to do so
unless we give guidelines and good reasons on why to do differently.

> Developers who use WSDL are used to the operation
> defining the contract. If you say "operation=state, verb=GET", and the
> effective operation is GET and not "state", then I expect that will be
> very confusing to them.

Why should it be? They map their Bulbs.state(bulbId) to an HTTP GET
operation. It's better than naming their method Bulbs.GET(bulbId). The
issue will be to provide an easy way to do this mapping at the
programming language level but more and more language are now providing
annotation systems. Adding type='application' is certainly going to add
confusion since that having two ways to do the same thing is always
confusing. Unless the user is well-informed on the meaning of the HTTP
verbs, he will end up misusing them; and the easier is it for non-Web
aware users to develop Web applications, the more likely it will that
they will misuse it. 

Philippe

Received on Thursday, 29 May 2003 17:21:07 UTC