For a start, SOAP is transport agnostic whereas REST is designed to use the features of HTTP. REST goes much further than just using pretty urls. e.g. you making use of the correct HTTP verbs for your operations. SOAP doesn't make use of HTTP features because then you couldn't apply it to a non-HTTP transport.
It's easy to dismiss SOAP as poorly designed because REST does what you want more easily, but SOAP is capable of much, much more (and not just discovery) albeit with greater complexity. Also, in my experience many REST APIs fail to truly embrace the philosophy behind REST and simply use it to put different RPC style operations behind different urls. This is very true, but in a lot of cases people could easily use REST instead of SOAP and vice versa as they are just doing basic CRUD or workflow operations. IMHO SOAP still has its uses, it's just that in a large number of cases where it was previously used was similar to hitting a nail with a sledgehammer when a normal hammer would have done the trick. Totally agree that most systems that use RPC style operations have just thrown most of HTTP's existing functionality out of the window. A few situations where SOAP would be a better choice over REST are systems which should be using UDP, systems which require a constant connection and stateful systems. ---- Michael Lyons
