Well in the past few days I've been reading some posts, which seem to bring back some close by history, James Governor is bored by SOAP and more to the point doesn't understand why vendors don't support REST. Mike Champion doesn't understand what all the fuss is about.
These are only two articles out of many. Mike kind of makes the point I want to make, and I agree with him completley. This is an old argument, that isn't really an argument at all. Basically everybody agrees on the issue, it just seems that the first side doesn't want to admit it.
Let's examine this: On one side (supposedly) we have REST, a simple way of calling a service through HTTP and getting an answer, in olden days this was some text, today it is usually an XML reply. This is undoubtably very simple to use, and too tell the truth is what I mostly use when developing Web based APIs. On the other hand we have SOAP together with all those WS-* and WSDL and the list goes on... This is a by far more complicated and cumbersome for developers, who rightly claim they don't want to learn this - who does?
The point is that these are actually two complementary solutions, they don't negate each other and can easily live together in the same application. However, they ARE different in a very essential way, as they are similar.
They are similar since both are used to call remote services through the network, actually invoke some function at a remote location (whatever that function may be).
They are different because of obvious reasons,
1. first they don't look the same. SOAP has much more gibberish (to human eyes) than REST. Basically the Calling syntax in REST is more simple than the one in SOAP (though the return can be baffling in both)
2. SOAP supports more methods of network transfer, while rest is very much attached to HTTP (not totally but still)
3. SOAP has a more strict way of making sure the message is OK, does anyone still remember those ugly exploits of IIS, just because of its support of REST (executing some system executable by reaching it through the URL)
4. SOAP supports (through those extensions) a wide array of authentication and encryption, and more... This might not seem as something that you can't do with REST (through SSL and IIS authentication for example). but in the SOAP case it is part of the protocol, and is implemeneted at the Service level, instead of the specific application (it follows a spec). Also SOAP + Extensions support this in more than just request/reponse model. which brings me to the next point.
5. SOAP isn't request response. HTTP is. This allows for just sending status notifications to many delegates without actually knowing them or caring.
I could go on and on, but the conclsion is the same, They are both here to use, use them when they apply, not for show.
One more thing, people are complaining about lack of tools for REST, well first there are many. Each normal webserver supports them by default. No normal CGI/* application server that deals with web ignores them. It is very easy to do it, all you need is a web browser, or some sort of HTTP control to manage the connection. Why do you need more tools than that. SOAP does need advanced tools. It is a complex thing that I can not work without some smart tool to tell me I'm doing it right.
Hope this makes sense to you...