Bryan Rasmussen writes:

> It don't think it translates well to document literal requirements, 
> and as noted it is a binding for RPC only right? 

Not quite.  SOAP works great with document literal.  Think of that stock 
quote example:  you can return the price of the stock using any reasonable 
XML <soap:body> element you like.  The reason RPC is discussed explicitly 
is that using GET appears to present a particular challenge if your 
original mindset was to try and implement an RPC like:

        returnedStockPrice = stockPrice(company="ibm", date="20071204");

The section you're referring to suggests that you might to do a GET to a 
URI along the lines of:

        http://example.org/stockprices?company=ibm+date=20071204

So, the GET support works either way; in the case of RPC, you have to 
decide that parameters that would have been encoded in the SOAP Request 
body will instead be in the URI designating the resource. 

BTW: I understand that you were not at any point intending to be 
inflamatory.  However, as several people have pointed out, when you say 
"with REST the winner" that is at best a pretty extreme 
oversimplification.   There are communities in which REST is winning 
(often for good reason), many in which SOAP is winning (arguably for good 
reason at least some of the time), and no doubt players on both sides of 
the question who don't understand the tradeoffs as well as they might. So, 
that makes it a bit harder to take the announcement of a winner as a joke, 
because the appropriate balance between REST and WS* remains a point of 
discussion within the community, and some of us have been working hard to 
make that a calmer and more reflective discussion all around.  I 
understand that is your goal too, but I hope you can see why some of us 
weren't happy with your original note.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------