I am sometimes asked: Why don’t you offer REST, it is better. But why is REST better? Especially people who demand REST don’t even know why it is better.
We read a lot of discussions on the net (http://spf13.com/post/soap-vs-rest).
SOAP supports ACID transactions – REST only CRUD. There are many discussions on a theoretical level, that don’t really help deciding what to use.
From my point of view everything is possible with both protocols. The difference in practical usage is, that REST has less build-in features, and is easier to parse. But when SOAP is used as web-service protocol, it is easier on the client-side.
Why is REST more popular than SOAP?
The large amount of features, like Schema, make SOAP a rather heavy weight protocol. This might be the reason why large companies like Google and Twitter count on light weight protocols like REST. It’s easier to parse, and saves millions of dollars for energy costs.
The reason why it is hard to parse is the schema. SOAP has a W3C Schema that defines the structure, and parsing costs a lot of machine-power. This schema parsing must also be implemented for all programming-languages. Most of them have SOAP by now, but it took a long time until it was perfect everywhere.
SOAP integrates better into IDEs
What is a disadvantage for companies with millions of transactions per second, is an advantages for the developer who implements it:
Almost all programming languages have a SOAP-Client. This SOAP client can read the web-service definition (WSDL) and validation and auto-completion is offered inside the IDE (best case). The objects on the remote side are mapped to the objects on the client side. The integration is seamless, clean, and validated, which is very nice for enterprise applications. Of course you could use a W3C Schema or other definitions, to describe RESTfull services. But these are not part of the Specification, IDEs and programming languages. There is no generation of classes or real-time validation.
Every programming language has a different way to interpret SOAP
This advantage can turn into a disadvantage on the side of the company which offers SOAP. As the mapping from SOAP definitions to classes is different for each programming language/soap client, support can be tricky. The class-structure of PHP, Java-Axis, Java-Axis2, .net and others are different. An Example: Sometimes there is one class “Extensions Extensions” (old), sometimes there are two classes “Extensions”, “Extension” (new). It is harder to support this. Some companies, like Ascio have Code-Examples (http://aws.ascio.info/cg.html) for each language to solve this issue.
The SOAP WSDL helps programming without documentation
On the other hand, when stub-classes are generated from the WSDL, programmers can work with SOAP without documentation. Everything that is needed is offered through auto-complete. It is possible to inspect the class-structures inside the IDE. Validation is done while typing the code.
REST works with JavaScript
If you want your web-service to be used in the browser – via JavaScript – REST is the easy way to use. As JavaScript doesn’t have an internal SOAP-Client, REST has advantages. It integrates good in frameworks like Angular that implement an HTTP-based document model.
Summary
Here a summary for the practical advantages/disadvantages:
REST Client:
- Easy to start
- Documentation needed
- Easy protocol
- Very popular
- Works good in the browser
- Only needs an HTTP-Client
SOAP Client
- Need to setup SOAP in your application once
- Documentation not needed for the structure
- Validation/Autocomplete, integrated into the IDE
- Complicated protocol
- Less popular than REST
- Needs a SOAP-Client
If you build something like a flexible document storage, where the validation of documents is not relevant, I would recommend REST. Also if it should be for the browser. If it is an object oriented application, where a valid document structure is very important, SOAP has advantages. Better Object Orientated Structure saves development-resources, better validation helps preventing errors before they happen. Setting up the SOAP-Client may be more work at the beginning, but then saves time.
So where does the future go to? When you compare real-life languages like Latin with modern languages you can see: Latin is very expressive, but hard to learn with a lot of overhead, we can observe that the world wants to simplify things. We can observe the same, when we discuss about JSON vs. XML. The trend goes in direction REST, which doesn’t mean it is better or worse. It is just more popular, and you need less knowledge to start with it.
For the client it is the business-logic, exceptional rules, and other things, that make implementation difficult. A good programmer should be able to handle SOAP and REST. This is just the protocol.
References:
https://en.wikipedia.org/wiki/SOAP
https://en.wikipedia.org/wiki/Representational_state_transfer
Written by Manuel Lautenschlager on January 24th, 2017
Integration Specialist at Ascio. Expert XML and semantic technologies