Talk is in praise of SOAP, but not to talk trash about REST. Simpler protocols are great, but SOAP has it's place as well. REST stands for "REpresentational State Transfer, and everything is based on URI. Relies on HTTP verbs (GET, POST, HEAD, PUT, and DELETE). Encodes parameters and details in the URI. Where REST is simple and straightforward, SOAP is complex and opaque. There is a basic spec for SOAP, as well as WSDL, WS-I, etc. XML-RPC is a third alternative, that sits in the middle -- encodes parameters and details in XML like SOAP, but uses HTTP POST like REST.
SOAP criticisms:- Too complex
- REST more scalable than SOAP
- SOAP based on new and untested technologies (WS-I, for example)
- REST more accurately models system by keeping strong relationship between URI and resource. Don't hide details in XML config files ("XML sit-ups", to quote DHH).
The pitch is that REST and SOAP are not in direct competition. It is more like C vs. Java -- each tool has appropriate applications. Complexity is a gradient, not a binary switch. XML-RPC has SOAP beat in terms of number of implementations/platforms (80 implementations across 30 platforms). XML-RPC has some limitations that aren't being fixed in the spec?
More about complexity. Don't confuse complexity with detail -- Amazon can provide a lot of detail based solely on the ASIN in a REST call. It seems like one of the limitations of REST might be if you have variable-length arguments. Creating a REST URI that can accept this sort of data could be complicated and/or ugly. Is that the point of this talk? No way to define a contract with REST, as opposed to SOAP.
On the whole, I still don't understand what the benefit of SOAP is. It just seems like a massive PITA, and REST seems so much easier. Hmm...
-Andy.