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

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

"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??

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

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

I have no problem with you raising issues against SOAP 1.2, but IMO
they made the right pragmatic decision in dealing with GET/POST .. the
only two methods that I personally would open up on any production
server :-).

Sanjiva.

Received on Monday, 12 July 2004 13:59:51 UTC