Most of my career I have dealt with Banking, High Integrity, HIPPA, PCI, and Financial data. When dealing with these kinds of data the main things you need to be worried about are:
- Ability to perform distributed transactional functions
- Verification of identity through intermediary (not just point to point IE. SSL)
- Standard implementation of data integrity and data privacy.
For the above data types the three things above aren’t a option you must implement them and SOAP does all three with WS-Security, WS-AtomicTransaction, and WS-ReliableMessaging.
REST is limited by the HTTP protocol itself and the stateless nature of the web for things like transactions and expects you to handle errors in communication. SOAP on the other hand provides two-phase commit across distributed transactional resources, has successful/retry logic built in, non-repudiation through signed messages, and support for signature formats: SAML Certificates- Kerberos tickets-x.509 certificates. SOAP also has the ability to encrypt the messages itself and a few other nice features such as attaching security tokens built in natively. This combination of things along with proper use of ciphers, formats, and algorithms leads to what is called end to end security which is a requirement for the above mentioned data tpyes to be compliant with industry standards and in some cases federal law. For anyone who does not need these things REST is great but for secure data, strong typing, and support for numerous security mechanisms to ensure safe use and reliable data you use SOAP.
Atomic Code 