Re: HTTP binding for WSDL 1.2

On Thu, 2003-05-29 at 13:52, Mark Baker wrote:
> Hi Philippe,
> 
> On Thu, May 29, 2003 at 10:57:22AM -0400, Philippe Le Hegaret wrote:
> > Remove the operation constructions for this case would force us to
> > inline the parts inside the HTTP binding, which is against the
> > reusability of the interface imho.
> 
> Well, there's the rub 8-); an application protocol defines an
> interface, so it isn't reusable with other application protocols.

agreed, but I'd better keep the concept of interface than enclosing an
operation into one application protocol. When I look at the various
application protocols used in instant messaging, I'm quite happy to have
softwares that define a common interface to access them.

> > Wouldn't change
> > anything and the URI constructed will still be
> > http://www.example.com/bulbs?buldId=42
> 
> Yes, the URI would be the same, but there are other considerations.
> 
> Currently, there's an implicit understanding in the use of WSDL, that
> a client wanting to use a service with a WSDL description has to
> understand what the wsdl:operation means in order to use it, as that
> is what it is being asked to happen.  If the wsdl:operation is "state",
> but a client doesn't need to understand what that means, and instead
> only needs to understand what HTTP GET means, then that makes
> wsdl:operation superfluous.  This is the point of issue 64, and I
> attempted to address that with an earlier proposal (see below).

I doubt that a WSDL processor would agree to accomplish an HTTP GET
operation just because it happens to be an HTTP GET. WSDL doesn't
contain a lot on the meaning of an operation in any case. At most, you
can conclude (or hope) that doing the operation twice won't affect
anything. Knowing that state is a GET won't tell you what to do with the
result of the operation.

> > I'd be certainly willing to consider a concrete proposal for the HTTP
> > binding if the current doesn't address your concern,
> 
> Well, I made a proposal that would resolve my issue, though it's
> not a HTTP binding; it (optionally) removes the need for bindings
> altogether when using an application protocol.
> 
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0103

Thanks for the pointer!

I fell to see the value of the distinction between application and
transport in your proposal. HTTP verbs are always bound to their
semantics defined in RFC 2616. What would be the difference of using 
the binding/@type attribute with "application" and "transport" when HTTP
is in use?
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.

Philippe

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

Received on Thursday, 29 May 2003 15:54:05 UTC