In the context of the Web, the REST approach is the preferred and most cost-effective architectural style for implementing services due to its scalability, its ability to allow dynamic connectivity without prior planning, its ability to enable independent evolution of clients and services, and its built-in support for caching and security.
There are several major problems with using SOAP in the Web environment:
- The resource being targeted is not known simply from the URL. It is hidden within the SOAP message.
- The method being invoked is not known from the HTTP method. It is also hidden within the SOAP message.
- The set of methods is completely arbitrary. Every SOAP application is free to define its own set of methods.
As we have discussed these problems create an impedance mismatch with today's Web - SOAP messages cannot be utilized by proxy servers, cache servers, etc. The lack of URLs within SOAP messages is very foreign to the Web, and isolates itself from the Web. Finally, the evolution of the Web is where every resource is identified with a URI. SOAPs clumping of resources behind a single URI is contrary to the Web vision.
So what is the role of SOAP? SOAP is best utilized in closed systems (systems where all participants are known beforehand). In a closed system each participant can be customized to understand the APIs of the other participants and can be optimized for maximum efficiency.