W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

Re: SOAP Web Method Feature, interface operation & HTTP binding (issues 54 & 64)

From: Hugo Haas <hugo@w3.org>
Date: Thu, 15 Apr 2004 09:57:50 +0200
To: David Orchard <dorchard@bea.com>
Cc: www-ws-desc@w3.org
Message-ID: <20040415075750.GA27754@w3.org>
* David Orchard <dorchard@bea.com> [2004-04-14 11:46-0700]
> Firstly, on naming, I'm uncomfortable with the use of the term "web
> method" when describing a generic (REST) operation.  WSDL uses the term
> "name" within an operation for specifying the name of the operation.
> Thus I prefer "name" to "method".  Further, the notion of "web" has too
> specific a meaning for me as it has a couple of different connotations.
> For example, is it only for HTTP operations?  That is, if I bind a
> web-method of "put" to IIOP, does it really make sense to call it a
> "web" method?  In which case it really is just a binding issue.
> Further, the Web is really defined to be about a network of resources
> identified by URIs.  If my binding doesn't use URIs, then using the term
> "web" method again doesn't make sense.  The abstraction that I think is
> important is that the "method" is a constrained interface.  Hence why I
> call it "restName".   Also, because the use of the "web method" aka
> "REST name" is applicable to the non SOAP HTTP binding, I prefer
> decoupling from the soap 1.2 term. 
> The way I look at it, the interesting idea is that an operation actually
> has 2 names, rather than just one.  It might be more accurate to
> describe them as "customName" and "constrainedName", but that seems
> cumbersome.  And I'd rather predispose things to treat the current use
> of name as the 80/20 point, that is the simplest.  To me, the idea is
> that this makes the simple thing (having 1 name) the simplest, and makes
> the hard thing possible.
> Now I'm prepared to live with calling this a "web method" because of the
> way that soap 1.2 treats this.  And I can CERTAINLY live with it if it
> turns out we spend a whole bunch of time arguing about the name....

As you mentioned, the name really comes from the fact that I didn't
want to introduce a new mechanism but rather reuse an existing one.
I'm afraid that renaming would mean redefining an identical feature.

> Secondly, I'd like to think of a way of using that web method/rest name
> in the binding.  Strawman: the http:binding could have an attribute for
> re-using the webMethod, ie UseWebMethodAsHTTPOperations="true"...

I like that. That would be an interesting way of explicitly linking
the HTTP binding of an operation to the Web method / REST name, and
may well be a good candidate for a solution to the syntax discussion
Jonathan and Mark had around issue 64.

> Thirdly, I think there is a binding issue about binding abstract web
> methods to different HTTP verbs.  Some corner cases: Atom's binding of
> PUT and DELETE to HTTP POST, and binding of GET to POST for containing
> Query bodies, aka XQueries.

I don't think that it would be an issue though. The text I proposed
encourages people to use the right method for their binding (SHOULD),
but doesn't preclude to do other things.



  1. http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-bindings.html#_operation_uri_style
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Thursday, 15 April 2004 03:59:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC