SOAP web service
RESTful web service
|Java API for SOAP web service is JAX-WS.
||Java API for RESTful web service is JAX-RS.
|Simple Object Access Protocol (SOAP) serves as a standard
protocol for web service creation.
||Representational State Transfer (REST) is an architectural
style for web service creation.
|Web services and clients are tightly coupled and define some
standards that need to be strictly followed.
||It does not follow many standards and is loosely coupled.
|It requires more bandwidth and resource as well as uses service
interfaces for exposing business logic.
||It requires less bandwidth and resource as well as uses URI
(Uniform Resource Identifiers) for exposing business logic.
|Permits XML data format only.
||Permits data formats like Plain text, HTML, JSON, etc.
|It is usually less preferred
||It is usually more preferred
|SOAPUI can be used for testing SOAP web services.
||Browsers and extensions such as Chrome postman are used for
testing RESTful web services.
|Its own security and uses WSDL contract for binding web
services and client programs.
||It does not have any defined contract as well as does not have
its own security methods.
|Standard communication protocol on top of transport protocols
such as HTTP, SMTP, Messaging, TCP, UDP, etc.
||transmitted over transport protocol such as HTTP(S).
|cannot be cached
||can be cached
|Supports both SSL security and WS-security
||Supports only point-to-point SSL security
|Has comprehensive support for both ACID based transaction
management for short-lived transactions and compensation based
transaction management for long-running transactions. It also
supports two-phase commit across distributed resources.
||REST supports transactions, but it is neither ACID compliant
nor can provide two phase commit across distributed
transactional resources as it is limited by its HTTP protocol.
|SOAP has success or retry logic built in and provides
end-to-end reliability even through SOAP intermediaries.
||REST does not have a standard messaging system, and expects
clients invoking the service to deal with communication failures
WS-Security maintains its encryption right up to the point
where the request is being processed.
WS-Security allows you to secure parts (e.g. only credit
card details) of the message that needs to be secured.
Given that encryption/decryption is not a cheap operation, this
can be a performance boost for larger messages.
It is also possible with WS-Security to secure different parts
of the message using different keys or encryption algorithms.
This allows separate parts of the message to be read by different
people without exposing other, unneeded information.
SSL security can only be used with HTTP. WS-Security can be
used with other protocols like UDP, SMTP, etc.
Client encrypts all of the requests based on a key retrieved
from a third party. When the request is received at the
destination, it is decrypted and presented to the service. This
means the request is only encrypted while it is traveling between
the client and the server. Once it hits the server (or a proxy
which has a valid certificate), it is decrypted from that moment
The SSL encrypts the whole message, whether all of it is
sensitive or not.