REST and SOAP for Services

First of all, in the title REST and SOAP is explicitly chosen for the word AND. I do not see any reason why there should be an exclusive or. There are already enough ((almost) religious) wars in IT, and in the world in general.

Besides that it can be hard to compare these two. How should one compare a software architecture (REST) with a protocol (SOAP)? Frankly, I don’t know. What I do know is that both are ways to implement a Service. And sometime during the A(architecture) part while implementing a SOA there have to be guidelines when to use SOAP and in what cases to use REST. In the mean time SOA as an architectural model stays neutral to technology platforms.


REST (the origin of REST) is closer to the web’s protocols. Or the other way around, the larger part of the World Wide Web conforms to the REST principles. RESTful services do not require WSDL operation specs. Since standard methods of HTTP (GET, PUT, POST, DELETE) are used, the number of operations is predictable.
The principles underlying REST result in advantages including:

  • Less software has to be written on the client side;
  • There will be less dependence on software (vendor) specific implementation;
  • It is easy to understand, due to hyperlink representation.


SOAP is a protocol working in a RPC way for exchanging structured information. SOAP, WSDL and XML based messages, solved a part of the problem of how to (self) describe messages for the exchange of information. That was a great step. And when we started to work with these standards, we noticed that it was not secure. To solve this developers started to add information to the header. And over time a (WS) standard came that solved the security issues.

In the enterprise world, security wasn’t the only lack. There were a lot of other issues that had to be solved. This resulted in the WS-* stack. Which is, at this point in time, quite extensive. And that makes it hard to oversee it all. This has led to the point of view that SOAP and WS-* are complex and hard to implement. And WS-* can be hard to implement. However the complication is not due to the WS-* stack, but due to the fact that we live in a complex world and are trying to solve complex problems! OK, there is one part where it could be due to the WS-* stack: The fact that there is not a single managed set of specifications, that is consistent, will get a lot of people confused. This resulted in specifications that overlap and compete. Which doesn’t benefit it’s cause.

Web services based on SOAP and WS-* enable a lot of companies to exchange information and perform business functions, also meeting the non-functional requirements. Some examples: functional requirements (like the ones resulting in transactions) and implementation and architectural decisions (eg composite services) are better implemented with SOAP than with REST.


Both in everyday use where Amazon offers both REST and SOAP web services, as in a more theoretical view, the Dual Protocol Pattern, it can be seen that these two can coexist. Offering the same capability, and offering a capability for which a specific implementation fits best.

Leave a Reply

Your email address will not be published. Required fields are marked *