I have to deal with SOAP APIs at work (Google, I'm looking at you) and they are seriously the bane of my existence. SOAP and the people behind it need to die a slow, painful and lonely death.
You move the action and some parameters into the request itself. You change the representation from xml to json. You get rid of schemas and namespaces (which makes the service either better or worse, depending on its size). People seem to be very upset about SOAP wishing it death. What is it that you're actually complaining about?
Basically, it's a bunch of extra work and requires more documentation due to the complexity of it's implementations.
Also, SOAP libraries (e.g. Soap4r) are problematic (doesn't talk to Micro$soft's version of SOAP properly).
REST is over HTTP. Just about all programming environments have a HTTP library.
Also the complexity is needed when your size goes up. Even verifying that the requests make sense is easier with schemas. Right now there is some project for json-schema going on, but it's not crazy popular yet. SOAP can be self-documenting too with its own structure mappings, type restrictions, etc. etc.
Don't you think it's only delaying the fact you'll have to reimplement the same stuff at some point yourself (since json based rest simply doesn't provide them out of the box)? (yeah - I know rest is protocol independent, so you can have xml and schemas too, but majority of "rest" services just throw some json and hope it sticks ;) - too bad if it changes between versions)
The Web services I've used tend not to be super complicated. A handful of api calls tend to be used.
There's also versioning, which is handled well with a good url structure.
Also, the schema problem is more of a JSON vs XML issue. I personally use JSON because it's simpler for flatter data graphs. I also use JSON schema btw. XML does have the advantage of xpath (or css selectors) too.
But even in the REST + XML case, the XML is simpler than the XML + SOAP case.
Which brings up Content-Type. Rest can serve pretty much any content type in a way that's readable by almost any web-enabled client. Not so with SOAP. You need to have more software.
Basically, I can add these features on an as needed basis. REST is easier to work with right now and I probably will not need all of the features of SOAP. That's the gist of why it's less popular now.
And pay attention to the cross-stack arguments, to say nothing of the cross version differences.
You remind me of this guy on stackoverflow: http://stackoverflow.com/users/76337/john-saunders -- M.S. kool-aid, yummie!
I am still waiting for any feedback (not from John, just in general) on this question: http://stackoverflow.com/questions/2194316/good-book-for-wri...
I guess anybody who know how to do these would be out pillaging and plundering corporate "america", not writing books :-)
SOAP is a message protocol, it's perfectly possible (and indeed pretty common) to run SOAP over HTTP.
In fact that's probably the most common SOAP transport.
I feel this point never quite lands home with people who've never tried to use SOAP across ecosystems (ie not .NET-.NET, Glassfish-Glassfish, etc).
Put in plain terms: It just doesn't fucking work.
Take a look at WS-I, the standard which tells you just how you should implement all of the standards that came before it, if you actually want to talk to other implementations: http://ws-i.org/profiles/BasicProfile-1.2-WGD.html
I first looked at SOAP in 2007. It made more sense to me after I read this: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...