[
Lists Home |
Date Index |
Thread Index
]
Aaron Skonnard wrote:
>
>...
>
> The SOAP operation is identified by the qualified name of the payload
> element.
The SOAP messaging framework does not even have a notion of operation.
Do a search in:
* http://www.w3.org/TR/soap12-part1/
So you cannot interoperably depend on that top-most element meaning
anything in particular. Now the optional SOAP RPC conventions do have a
notion of method.
But anyhow, you are missing the point. An application protocol has
*well-known methods*. Read the specifications for SMTP, FTP, HTTP,
WebDAV, Telnet, Gopher, etc. The clients and servers for these protocols
have the methods *hard-coded into them* so that interoperability between
clients and servers does not require out-of-band negotiations between
the client programmer and the server programmer. You start an FTP
client, it connects to an FTP server and all the programmer needs to
know is what file you want. You don't have to negotiate the methods you
use to even *talk about files*. That's why it is an application
protocol.
Obviously I am critical about SOAP but even among SOAP fans I thought it
was agreed that SOAP is not an application protocol. You can build
application protocols on top of it, but it isn't one itself.
> > 2. what URI you want to get. If you read the HTTP spec
> > you'll find that there is a ton in there about the
> > interpetation of that and of course behind that is the entire
> > body of Web standards
>
> A SOAP service is also identified by a URI (any transport).
That is not true. I refer you again to the SOAP specification.
* http://www.w3.org/TR/soap12-part1/
"Some underlying protocols may be designed for a particular purpose or
application profile. SOAP bindings to such protocols MAY use the same
endpoint identification (e.g., TCP port number) as the underlying
protocol, in order to reuse the existing infrastructure associated that
protocol."
So when SOAP runs directly over TCP, it does not use a URI, but rather a
port number. And when SOAP runs over HTTP it is essentially impossible
to use URIs to identify resources other than the so-called "SOAP
endpoint." For instance it is quite difficult to make a SOAP service
that gives URIs to individual purchase orders.
> > 3. the version of HTTP in use.
>
> The version of SOAP is identified by the SOAP namespace.
Okay.
>...
>
> I think "tearing down" is dramatic. SOAP embraces HTTP and tries to
> clearly codify its use to help ensure interoperability. This is where
> you'd like to see REST come in, right?
SOAP doesn't embrace HTTP, it abuses HTTP. Every SOAP service I have
ever seen deployed contradicts the guidelines of the HTTP specification,
the documented Web architecture and the findings of the TAG.
Paul Prescod
|
