[zargath]

Comparing REST to SOAP, is to me like comparing HTML to SASS/LESS.

SOAP had so many flaws, no need to repeat. But the fact that you could not trust that SOAP software created using Microsoft software would work with something created with Java software was a disaster. Sometimes I ended up building custom SOAP libraries to connect with the other services. It was promised to solve all our problems, but ended up creating more.

REST is not a "standard" library, it is just a basic guideline on how to use the HTTP protocol "out of the box".

What the author seems to be looking for, is one hammer to fix all problems.

If you are spending too much time writing REST services, maybe your frameworks are flawed, you could be automating more or your interface is too complex?

[sqldba]

Why did SOAP not work between MS and Java?

[jdbernard]

SOAP is a very complicated spec, and intended to be used to automatically generate bindings in whatever language you're using base in the service definition fine (WSDL). It's not intended to be human-readable.

So to provide a SOAP framework you need to not only provide all the plumbing for dealing with the actual messages, but all the rolling to auto-generate the client library for an API. The whole mechanism is very complex and there were lots of places where the spec was not specific enough, or the implementations had slightly different opinions about interpretation.

Then on top of that, Microsoft for a good while purposefully deviated from the spec to provide "enhancements" that other implementations had to reverse engineer to be compatible.

Then on to of that you had a whole raft of extensions to the spec like WS-Security, WS-Reliability, and (ironically for a "standard") WS-Interoperability. The chances that all of those specific extensions worked across different implementations was even more remote.

So, there were two big reasons in my opinion, that SOAP failed and REST shined:

1. The only way you could really trust that your SOAP client would generate compatible bindings for an API is if you wrote the API. This defeats the purpose of having public APIs. The author's complaint about REST implementation taking hours when his known tools take minutes rings hollow to me because I've spent weeks trying to get two simple SOAP systems communicating.

2. SOAP reinvents the wheel in a much more complicated fashion. Mant of those WS-* extensions were written to provide things that you already get if you embrace the existing networking stack (TCP/IP, HTTP, etc.). SOAP was trying to be transport-agnostic, so it ignored the existing stack and had to reinvent most of it itself. One of the key principles of REST is to embrace HTTP and let the existing system do with for you.

For example, SOAP used POST requests for everything. So all the tools that work with HTTP requests on the wire have to be rewritten to understand SOAP semantics instead of just looking at the request method.

Most of the use-cases in practice of WS-Security is covered by TLS/SSL. Theoretically WS-Security provides more flexibility, and can handle use-cases that TLS/SSL can't, but in practice it leads to over-complicated and less-secure systems.

WS-Reliability exists because you might use SOAP over something that isn't TCP. Most of the guarantees WS-Reliability gives you could have gotten for free if you entrance TCP.