Bryan Rasmussen writes:



> That SOAP did not identify bindings for GET was
I think its downfall

> (sorry, I believe in the war metaphor).



Oh, come on.  The tone of this discussion is
pretty disappointing for a variety of reasons, but if you make a statement
like this please at least read the pertinent specifications.  Quoting
what is probably the most relevant part of the SOAP 1.2 Recommendation
[1]:



--------



4.1.2 Distinguishing Resource Retrievals from other
RPCs
The World Wide Web depends on mechanisms that optimize
commonly performed information retrieval tasks. Specifically, protocols
such as HTTP [RFC
2616] provide a GET method which is used to
perform safe retrievals, i.e., to perform retrievals that are idempotent,
free of side effects, and for which security considerations do not preclude
the use of cached results or URI-based resource identification.
Certain procedure or method calls represent requests for
information retrieval. For example, the call:
getQuantityInStock(PartNumber="123")
might be used to retrieve the quantity established in the
example above.
The following conventions can be employed to implement
SOAP retrievals and other RPCs on the Web: 

The conventions described in 4.1.1
Identification of RPC Resources are used
to identify the resource with a URI. 
In cases where all the arguments have been represented
in the URI, no SOAP header blocks are to be transmitted and the operation
is a safe retrieval, the 6.4
SOAP Web Method Feature and the 6.3
SOAP Response Message Exchange Pattern are
used. Accordingly, no SOAP envelope is
transmitted for the request, and the http://www.w3.org/2003/05/soap/features/web-method/Method
property is set to "GET". The results of the retrieval are a
SOAP RPC response as described in 4.2.2
RPC Response
In cases where the operation to be performed is not a
retrieval, when SOAP header blocks are to be transmitted (a digital signature,
for example), or when a retrieval is not safe, the 6.4
SOAP Web Method Feature and the 6.2
SOAP Request-Response Message Exchange Pattern
are used. The request envelope is encoded as described in 4.2.1
RPC Invocation, and the results are as described
in 4.2.2
RPC Response. The http://www.w3.org/2003/05/soap/features/web-method/Method
property is set to "POST".The SOAP RPC
Representation does not define any other value for the http://www.w3.org/2003/05/soap/features/web-method/Method
.



--------



Also [2]:



7.1.3 Interoperability with non-SOAP HTTP Implementations
Particularly when used with the 6.3
SOAP Response Message Exchange Pattern,
the HTTP messages produced by this binding are likely to be indistinguishable
from those produced by non-SOAP implementations performing similar operations.
Accordingly, some degree of interoperation can be made possible between
SOAP nodes and other HTTP implementations when using this binding. For
example, a conventional Web server (i.e., one not written specifically
to conform to this specification) might be used to respond to SOAP-initiated
HTTP GET's with representations of Content-Type
"application/soap+xml". Such interoperation is not a normative
feature of this specification. 
Even though HTTP often is used on the well-known TCP port
80, the use of HTTP is not limited to that port. As a result, it is possible
to have a dedicated HTTP server for handling SOAP processing on a distinct
TCP port. Alternatively, it is possible to use a separate virtual host
for dealing with SOAP processing. Such configuration, however, is a matter
of convenience and is not a requirement of this specification (see SOAP
1.2 Part 1 [SOAP
Part 1] Binding
to Application-Specific Protocols).



--------



We worked very hard to add this support.   In
case the above isn't quite clear, let me summarize the essence:  A
SOAP envelope has a media type (application/soap+xml).   You can and
should use it just as you would another media type.  For example,
if you want to return a stock quote, but want to put in a SOAP header that
indicates with a digital signature "this quote is sourced by XYZ Investments
Corp. and this digital signature prevents XYZ Corp from repudiating it"),
all you have to do is make up the appropriate SOAP envelope with the quote
in the body and the signature in a standard SOAP header, mint a URI for
the stock quote resource, and return then envelope using HTTP GET when
asked.



It is true, and very much a shame IMO, that many of the commercial implementations
fail to support this GET pattern, and/or that much of the tooling around
SOAP doesn't exploit it.  Supporting GET is the easy part;  the
hard part is building tooling that uses URIs in the right way so that each
stock quote gets its own, as opposed to just having one "QuotesRUS"
URI that serves lots of quotes.



So, there are serious issues about how the SOAP implementation
community has failed to provide the RESTful features of the SOAP Recommendation,
but to say that "SOAP did not identify bindings for GET" demonstrates
lack of knowledge of the pertinent specifications.  The specifications
are there.  If users of WS* want this, they should scream at
their vendors to implement it.  By the way, that non-repudiated stock
quote is an example of something that HTTPS, the usual security answer
from the REST community, doesn't even try to provide.



Just to be clear:  I'm a big fan of REST for
what it does well.  I spend a lot of my time on the TAG defending
it and/or clarifying it, and I was among those who worked very hard before
the SOAP Recommendation was published to put in those REST features.  I
also think there are many things SOAP does for which REST does not at this
point provide interoperable standards (specifically, a header model with
distributed extensibility, I.e. one that lets you invent your own URI-qualified
headers, and with a rigorous set of processing rules for them. and also
support for transports like reliable queuing systems such as JMS, WebSphere
MQ, etc.)  REST is also at the moment a stretch for transactions that
take 5 days to complete, etc. (please order these items and respond when
they ship).  I have many problems with how the upper level parts of
the WS* stack were built, and some problems with SOAP itself, but I think
there are important use cases that the current REST embodiments don't even
try to address.



By the way, a lot of this was discussed quite rationally
and in some depth at the W3C Workshop on Web of Services for Enterprise
Computing held last year.  Many REST and WS* experts/advocates participated,
including some such as Mark Baker who have been mentioned in this thread.
 Minutes are at [3] and a final report at [4].  I think it might
be worthwhile, before this debate goes too much further here, for those
involved to review what was covered there.  I think the light/heat
ratio might improve a bit.



Noah



[1] http://www.w3.org/TR/soap12-part2/#RPCResourceRetrieval

[2] http://www.w3.org/TR/soap12-part2/#httpinterop

[3] http://www.w3.org/2007/02/wsec-minutes.html

[4] http://www.w3.org/2007/04/wsec_report.html





--------------------------------------

Noah Mendelsohn 

IBM Corporation

One Rogers Street

Cambridge, MA 02142

1-617-693-4036

--------------------------------------