Re: Issue 169: Propose http method in the operation interface to simplify http binding.

Hi Sanjiva.

* Sanjiva Weerawarana <sanjiva@watson.ibm.com> [2004-07-09 19:14+0600]
> I still haven't seen a defined semantic of what @webMethod="GET" or
> @webMethod="POST" means in a generic sense. Can you please provide
> those semantics? What are the accepted values for @webMethod?

Actually, this was specified in my original proposal[1] (see 2.4.5 Web
method characterization), which was discussed and accepted with an
open issue on syntax, which is issue 169, during our 22 April
teleconference[2].

> Unless such semantics can be given *in an HTTP independent manner*
> and they can potentially be bound to other protocols, I'm most
> definitely -1 on adding @webMethod to interface/operation.

Maybe one thing which was missing from the first paragraph was:

  The Web Method property indicates that an operation has the semantic
  of the specified Web method.

Although the definition of the GET, POST, PUT and DELETE is indeed in
RFC 2616, I don't see them tied to HTTP. For example, GET on
ftp://example.com/foo also means "retrieve whatever information" is at
this address.

One thing to clarify is that Request-URI is the endpoint location.

> I would specifically appreciate your explaining the relationship
> between @webMethod and @safe (the latter of which we already have).

I think that the only relationship is:

  webMethod == GET => safe = true

> Also, in a SOAP world, how would @webMethod interact with
> wsoap:mep (and the implied HTTP method when SOAP/HTTP is in use)?

The SOAP 1.2 HTTP binding only has support for GET with the SOAP response
MEP and POST with the request-response MEP as explained in [3].

As a parenthesis: looking back to it, I am wondering if limiting the
request-response MEP's Web method property to POST wasn't a mistake:
cases where for some reason PUT and DELETE are unavailable and one
would have to use POST instead, like Atom suggests, can arise. Maybe
the HTTP binding should have allowed all values for the
request-response MEP and the SOAP Web Method Feature should have
defined a SOAP header indicating the Web method intended to be
included in the message when the binding uses a method different from
the one intended. Anyway, that would be an issue against SOAP 1.2.

Getting back to WSDL 2.0, my friendly amendment proposed at [4] is
actually incomplete incomplete. In the case of the SOAP HTTP binding
we are defining, the Web method property is restricted to GET or POST
depending on the MEP used, which would need to be specified.

Note that another HTTP binding could define support for other Web
methods and have different rules.

Regards,

Hugo

  1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html
  2. http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0085/22-ws-desc-irc.html
  3. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http-suptfeatures
  4. http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0295.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/