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

"David Orchard" <dorchard@bea.com> writes:
>
> There's 2 separate concepts: Constrained or Generic interface (ie REST)
> and the actual protocol verbs (GET/PUT/POST/DELETE) on the wire.  The
> use of "GET" can apply to many protocols, and even many bindings.

There are many constrained interfaces which have their value
in their own worlds. For example, if I'm designing a family
of services to deal with different I/O devices, I'd say the
Unix-style open/read/write/close interface is a constrained,
generic interface applicable for every I/O device.

My point is that the HTTP verbs are not so special.

> For example, might model an operation as a "GET" and then use the
> soap-response MEP by default in the soap binding.

Right, that's the canonical example for a GET .. what if its
some other binding?

> > Can someone explain what that means in SOAP and for RMI/IIOP?
>
> Sure.  In the case of SOAP, as we see in Atom, they can bind a
> "GET" operation to either HTTP GET or to SOAP.

When mapping to SOAP/HTTP will you require that it be bound
to "GET" or is "POST" ok too? If its the latter what is the
semantic of saying @webmethod="GET"? If its the prior, then
again you're looking at the special case of SOAP-Response MEP
which has built-in support for GET.

> In the case of SOAP, they set the soapaction to "GET".

As a WS-Addressing fan, I'd never do that .. my SOAPAction
will be the dispatching key for the service.

> They can bind a "DELETE" operation
> to: HTTP DELETE, HTTP POST with a DELETE body, or HTTP POST with a
> SOAP body of DELETE.

What's a SOAP body of DELETE??

> The concept of "DELETE" maps to SOAP and HTTP.

I fail to see how it maps to SOAP .. of course it maps to HTTP
because that's where it came from.

> Now the Java community could come up with a GET/PUT/POST/DELETE RMI/IIOP
> class that would be a natural mapping of constrained interface to
> RMI/IIOP.  I wouldn't expect the WSDL WG to do that, but maybe
> JAX-RPC xyz.  And MSFT could do the same for .NET remoting.

RMI interfaces are just arbitrary interfaces. What does it mean
to map to a constrained interface there?

In any case, *what* are they mapping? How are the semantics of
@webmethod=".." defined? What are they for each value and
do you allow other methods as those used by WebDAV .. and
what about M-GET etc.?

> So let's see: We can design our schemas in the abstract to say that the
> method is in the body in a certain format, but yet we can't say that the
> method is a particular named method?

Its of course more than that its a "particular named" method right?
The use of @webMethod=GET is meant to invoke some semantic of
the operation. That is not the case for @style.

> If you *know* you are sending over HTTP
> natively, you probably won't use rpc style because you'd know the method
> is in the protocol.

Sure you would .. RPC style doesn't affect the messages; its
simply a style of how the schemas were written. That by no means
requires that the dispatching be done via the first element
local name! So I still will use WS-Addressing and <Action>
to indicate the dispatch.

> Atom is a good example, they use an rpc style encoding
> when they have to bury(tunnel) the method inside the body.

I'm sorry but I haven't had a chance to go thru Atom yet .. :-(.

> Saying in the interface "the input to GetStockQuote is the GetStockQuote
> Schema which follows the RPC style encoding" is *the same* as saying in
> the interface "the input to GetStockQuote is the GetStockQuote Schema
which
> is a document/literal encoding and the method is GET".  In both cases the
> abstract interface defines the method.

What does "method is GET" *mean* in a binding independent manner??
I'm sorry for being so thick about this, but I haven't seen anyone
define crisp semantics for the various values of @webMethod .. if
I missed it pls point me to it.

Sanjiva.

Received on Thursday, 1 July 2004 10:12:23 UTC