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

* Sanjiva Weerawarana <sanjiva@watson.ibm.com> [2004-07-12 23:59+0600]
> (I don't understand why but all of your messages' root MIME part also
> gets displayed in my mail reader as an attachment. Doesn't happen for
> anyone else. Weird.)

(It probably is because your mailer doesn't support RFC 3156, MIME
Security with OpenPGP.)

> "Hugo Haas" <hugo@w3.org> writes:
> > 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].
> 
> I looked up [1] and it doesn't really give a semantic for
> what @webMethod means for an *arbitrary* operation. It just
> says that for protocols which are designed to manipulate
> resources these verbs make sense. 
> 
> If we're going to put @webMethod on /definitions/interface/operation
> then we need a very well defined semantic for what that means 
> without referring to HTTP specific things or SOAP specific things.
> Your reference doesn't provide either!
> 
> You say that we reduced it to a syntax issue .. but AFAIK we
> reduced it to a syntax issue *within the http binding*: whether
> to provide explicit syntax or use the F&P syntax. We never 
> accepted to put this thing on interface operation components
> AFAIK. Did I miss something that criticial??

As I said in the follow-up email I sent, I now think that it was a
mistake to propose the SOAP Web Method Feature for this job. So let me
try and restate this independently of the feature.

When specified on an interface operation, the webMethod
attribute|property specifies that this operation has semantics
equivalent to the following Web methods, as defined in RFC 2616:
- GET: retrieve whatever information is identified by the [endpoint
  location].
- POST: accept the [message] as a new subordinate of the resource
  identified by the [endpoint location].
- PUT: store the [message] under the supplied [endpoint location].
- DELETE: delete the resource identified by the [endpoint location].

(Note that I used square brackets to translate RFC 2616 language into
equivalent WSDL 2.0 language.)

To answer another question about the value space of webMethod, I
believe that it should be GET, POST, PUT and DELETE, and be extensible
in case the community comes up with a new Web method — which is also
the value space of the SOAP Web Method Feature method property[3]:

| One of "GET", "POST", "PUT", "DELETE" (or others which may
| subsequently be added to the repertoire of Web methods.)

> > 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.
> 
> So what does GET on mailto:sanjiva@opensource.lk mean? I don't see
> how you can make such arbitrary application of the HTTP verbs 
> to any old URI and expect it to make sense .. if you explain the
> above try DELETE mailto:sanjiva@opensource.lk too!

I don't think that @webMethod would necessarily map well to all
bindings. Though I guess in your example your could define a binding
for email which would provide such facility, e.g. IMAP and POP
bindings.

> > I think that the only relationship is:
> > 
> >   webMethod == GET => safe = true
> 
> In other words, we don't need @safe anymore .. we already say that
> @safe=true MUST means its safe and no information is given otherwise.
> Since @webMethod=GET MUST also means its safe, saying @webMethod=GET
> will achieve the same thing.

I remember, during the discussions around @safe, some people arguing
that an operation could be safe while not having the semantics of GET.

Regards,

Hugo

  3. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#webmethodstatemachine
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/