Recently, we had to determine the best way to communicate to a web service that was being developed. The use cases for this web service required it to be platform and language agnostic, it also had to allow stateful operations. To handle this, we narrowed it down to two messaging protocols: SOAP and REST. While both are widely used in the wild and there are arguments for and against both, we ultimately decided on using SOAP.
The decision ultimately boiled down to one of comfort for the developers and the tools that were internally available to us. Both options have clear advantages and disadvantages:
SOAP is both platform and language agnostic, which was required for our web service, but it also had the additional benefit of being transport agnostic. While it is usually used over an HTTP or HTTPS connection it can also be used over SMTP if it was deemed necessary. Also, it met another requirement of allowing stateful operations, allowing the system to handle contextual information. Since the target use of this web service is for enterprise solutions a certain amount of reliability and security were desired; SOAP provides both of these things standard. For security the protocol can operate through HTTPS using (among others) X.509 certificates; use the WS-Security extension to provide end-to-end security, provide non-repudiation, and provide security through alternative transport bindings; and the payload of the soap message can be individually encrypted by use of a symmetric key to allow for an additional layer of protection. Another extension that can be implemented to introduce reliability to the system is WS-ReliableMessaging. This extension allows for the reliable delivery of SOAP messages where software, network, and system failures exist. An added benefit of SOAP is built in error handling through Faults. These faults provide invaluable information when trying to debug an issue with the delivery of a message.
SOAP messages are composed of XML. This adds overhead to the client and server when parsing the message, and can potentially be a slow operation. When SOAP is relying on HTTP/S as its transfer protocol and is not using WS-Addressing, the interfacing parties are fixed.
One of REST’s primary advantages is its ease of implementation on the client side of an application. In addition to this idea of ease of implementation, the results of a REST call are also easily human readable. Unlike SOAP, REST does not have a lot of extra XML markup allowing any implementation of it to be comparatively lightweight. It only requires a HTTP stack to work, so there is an argument to be made that REST is more interoperable than SOAP; despite the fact that SOAP was designed with that exact thing in mind. With REST not only is the client and server implementation usually a more lightweight solution, but they also tend to use less bandwidth than their SOAP counterparts.
The most glaring problem with RESTful web services is that they have no built-in standards for security or reliability. While it is completely possible to build this into a RESTful SOA solution, it is often complicated and requires an error-prone, time consuming “roll your own” approach. The key problem that arises with the lack of a standard method to handle messaging reliability is for operations that are sensitive on the amount of times they are performed. For example, if you want to perform an operation against a payroll service that adds a bonus to an employee’s upcoming paycheck, you would not want to accidently and unknowingly send the same message twice; causing a discrepancy in the amount they should be paid and the actual amount they are paid.
In choosing a way to communicate with web services, we ultimately chose SOAP because of its perceived security advantage in the enterprise world. However, by breaking down the facts of both REST and SOAP, it all comes down to how each can be applied to your situation. Depending on familiarity with the two variations and how it suits the variables, both are very good solutions.
I hope you have enjoyed reading this blog post. I welcome you to post comments and questions below and look forward to answering them!
Interested in reading similar articles, check these out: