W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2003

Re: HTTP binding for WSDL 1.2

From: Mark Baker <distobj@acm.org>
Date: Thu, 29 May 2003 21:19:18 -0400
To: Philippe Le Hegaret <plh@w3.org>
Cc: www-ws-desc@w3.org
Message-ID: <20030529211918.H21907@www.markbaker.ca>

On Thu, May 29, 2003 at 05:21:06PM -0400, Philippe Le Hegaret wrote:
> > 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).

Sorry, I should have been clearer.  By "them" I meant the service
user, not the publisher.  For the RESTful case, the service user has no
need to understand what "state" means, and so IMO, they shouldn't even
see it.

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

But it's not the same thing, is it? 'type="transport" would make the
effective operation "state", and 'type="application"' would make it

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

I expect that most users will continue to use "type='transport'"
(which should be the default for that reason).

"type='application'" is just meant for publishers of RESTful services.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment
Received on Thursday, 29 May 2003 21:15:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:30 UTC