Lately I read a lot of articles about the advantages of REST over SOAP. All of them were right. But all of them considered special cases for communication between applications. Most of the cases considered communication between a server application and an application running on a mobile device. Of course I agree, REST is better than SOAP for this use cases. The main advantages are the following:
- REST requires less bandwidth to transfer data
- You can make Http calls from nearly every device without any constraints
- Serialization den deserialization is more lightweight and requires less process time (saves power and battery on mobile devices)
But in my opinion SOAP hast one main advantage over REST. This advantage is type safety, even at compile time.
Take the following example: Imagine you design an application architecture for a distributed system consisting of multiple "middleware modules" running on different machines. Each of those middleware modules needs to communicate with some other middleware modules. You don’t want to make your communication interfaces of your middleware modules public available because you consider this as an internal part of you application and you don’t want a third party to talk to those interfaces.
I encountered multiple similar cases like this in the last time. In those cases I always decided to choose SOAP using WCF over REST using Web API. I designed my communication interfaces using WCF in a separate assembly. I then referenced this assembly from the communication partners. In the client/consumer I always create my ServiceProxy on the fly in code using the interface defined in my assembly mentioned before. With this approach I get compiler errors if I changed my communication interfaces and forgot to rework the code of one communication partner. I see this as a big advantage and a feature you can use especially in quality management.
So keep in mind: REST is better in most cases, but don't forget SOAP!