SOAP Web service
|
RESTful Web service
|
SOAP (Simple Object Access Protocol) is a standard communication protocol on top of transport
protocols such as HTTP, SMTP, Messaging, TCP, UDP, etc.
|
REST is an architectural style by
which data can be transmitted over transport protocol such as HTTP(S).
Each
unique URL is a some representation of a resource (i.e Object like Account,
Customer, etc), and you can get the contents of the resources (i.e Objects)
via HTTP verb “GET” and to modify via “DELETE”,”POST”, or “PUT”.
|
SOAP uses its own protocol and focuses on exposing pieces
of application logic (not data) as services. SOAP
exposes operations. SOAP is focused on accessing named operations, which
implement some business logic through different interfaces.
|
REST is
about exposing a public API over the internet to handle CRUD (Create, Read,
Update, and Delete) operations on data. REST is focused on accessing named
resources through a single consistent interface.
|
SOAP only permits XML data formats.
|
REST permits many different data formats like XML, JSON
data, text, HTML, atom, RSS, etc. JSON is less verbose than XML and is a
better fit for data and parses much faster.
|
SOAP based reads cannot be cached. The
application that uses SOAP needs to provide caching.
|
REST based reads can be cached.
Performs and scales better.
|
Supports both SSL security and WS-security, which adds some enterprise security
features. Supports identity through intermediaries, not just point to point
SSL.
—
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.
|
Supports only point-to-point SSL
security.
—
The basic mechanism behind SSL is that the 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 on.
—
The SSL encrypts the whole message, whether all of it is sensitive or not.
|
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 by
retrying.
|
Which one to favor? In general, a REST based web service is preferred due to its
simplicity, performance, scalability, and support for multiple data formats.
SOAP is favored where service requires comprehensive support for security and
transnational reliability.
SOA
done right is more about RESTFul + JSON, favoring lighter weight approaches to
moving messages around than the heavyweight ESBs using WSDL+XML that gave SOA a
bad name
No comments:
Post a Comment