SOAP – Simple Object Access Protocol – defines a very strongly typed messaging framework which relies heavily on XML and schemas. REST -REpresentational State Transfer – is an architectural style which makes use of existing and widely adopted technologies, specifically HTTP, and does not create any new standards. REST can structure data into XML, YAML, or any other machine readable format, but usually JSON is preferred.
SOAP and REST – both provide support for building SOA based applications. The choice which one to use – largely depends on what really is required, from the business and an architectural point of view. By looking at both their strengths and weakness in certain environments, as well as understanding your own projects scope, you can make the most informed decision. So let’s list down their main differences which will help you in choosing one out of both.
Comparison of SOAP and REST APIs
SOAP itself is a protocol (over HTTP) for developing SOAP based APIs.
REST is almost synonymous to HTTP, though REST specification does not mandate it.
RESTful Web services are completely stateless. Managing the state of conversation is complete responsibility of client itself. Server does not help you with this.
Normally, a SOAP Web services are stateless – but you can easily make SOAP API stateful by changing code on server.
REST provide a good caching infrastructure over HTTP GET, PUT and (theoretically) DELETE methods thus enabling response data to to be marked as cacheable or not-cachable. The ETag header is a good way to implement caching providing you’ve got a cheap way to compute what the value should be.
SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests. As HTTP POST is non-idempotent, it can not be cached at the HTTP level. So, SOAP responses should be cached using information given in Response Caching Optimization Module.
HTTP Verbs Used
REST is primarily used over HTTP and it makes use of HTTP GET, POST, PUT, DELETE and PATCH methods for different CRUD operations.
SOAP also defines a binding to the HTTP protocol. When binding to HTTP, all SOAP requests are sent through POST request.
REST is based on HTTP – which itself is very unsecure protocol. It supports basic authentication and communication encryption through TLS. Any further security should be additionally implemented at server.
SOAP security is well standardized through WS-SECURITY, which is very much feature-rich and easy to implement into application code.
Asynchronous request processing may be required when creating/updating a resource is time consuming. In this case, REST suggest to return HTTP response code
202 Accepted and send location of queue where the status of task completion will be updated on frequent interval. REST got pretty good support for async APIs in JAX-RS itself.
If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.
Overall, REST is simpler to develop because it leverages the web, which is already in place and the degree of freedom is limited (less choices to make, so simpler). SOAP offers a number of alternatives and is also slightly more difficult to develop, but offers more alternatives and areas to work.