[vhackish]

SOAP is really for client side programmers that can't figure out how to do an HTTP request and parse XML all by themselves. Also the sell is that you can use automation tools to generate your client side code for you, but I found that they do not all behave the same way when dealing with anything mildly complex (like an array of objects for example). Data streams are also a PITA to deal with in SOAP, there's really no good provision for it. So do yourself a favor and wash your hands of SOAP (ha ha!)

[pak]

No, SOAP is for businesses that need a clear data contract in place when doing inter-business data integration with real money on the table. That's why it's been used in business APIs for nearly a decade. REST has nothing that parallels the functionality of a WSDL and all the tooling that has been built up around WSDLs. Without a WSDL, you don't have a computer-interpretable spec for the presented API, you have a bunch of human readable documentation, and REST has a huge gap between principles imposed by the philosophy and the protocol that allows for a wide variety in how APIs are designed. I don't think you understand the whole code auto-generation thing; SOAP can't generate much of the client-side code. It might generate the function signatures or an object that has the methods presented by the API. On the server-side, you can usually auto-generate a WSDL from a class definition or vice versa, which is a handy way to start turning that data contract into an implementation.

SOAP isn't going anywhere in the big-business world, but for smaller businesses/apps that can play faster and looser with data integration, I absolutely agree that REST is a simpler and more pleasant choice to work with.