SOAP versus RESTful Web service -- comparison
Recently I attended an interview with a large investment bank, and I was quizzed on SOAP versus RESTful web service. The interview questions were targeted at ascertaining my understanding of the differences, pros and cons of each, and when to use what.
Web services are very popular and widely used to integrate similar (i.e. Java applications) and disparate systems (i.e. legacy applications and applications written in .Net etc). It is imperative to understand the differences, pros, and cons between each approach.
Key
Area
|
SOAP
based Web service
|
RESTful
Web service
|
Specification/Platform
Fundamentals (SF/PF)
|
Transport is platform &
protocol neutral. Supports multiple protocols like HTTP(S),
Messaging, TCP, UDP, SMTP, etc.
Permits only XML data
format, hence language neutral.
You define operations,
which tunnels through the POST or
GET. The focus is on accessing the named operations and
exposing the application logic as a service.
Defines the contract via
WSDL.
|
Transport is protocol
specific. Supports only HTTP or HTTPS protocols.
Permits multiple data
formats like XML, JSON data, text, HTML, atom, RSS, etc.
Any browser can be used
because the REST approach uses the standard GET, PUT, POST,
and DELETE web operations. The focus is on accessing the
named resources and exposing the data as a service.
Traditionally, the big
drawback of REST was the lack of contract for the web service.
This has changed with WSDL 2.0 defining non SOAP bindings and the
emergence of WADL.
Simpler to implement.
REST has Ajax support. It can use the XMLHttpRequest
object.
Good for
stateless CRUD (Create, Read, Update, and
Delete) operations.
|
Performance
Consideration (PC)
|
SOAP based reads cannot
be cached. The application that uses SOAP needs to provide
cacheing.
|
REST based reads can be
cached. Performs and scales better.
|
Security (SE)
|
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.
|
Transaction Management
(TM)
|
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.
|
Quality of Service (QoS)
|
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.
|
Best Practice (BP)
|
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,
transactional reliability and stricter contract.
|
Q. Differentiate between SOA (Service Oriented Architecture) versus WOA (Web Oriented Architecture)?
A. WOA extends SOA to be a light-weight architecture using technologies such as REST and POX (Plain Old XML). POX compliments REST. JSON is a variant for data returned by REST Web Services. It consumes less bandwidth and is easily handled by web developers mastering the Javascript language
SOA and WOA differ in terms of the layers of abstraction. SOA is a system-level architectural style that tries to expose business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumers. You can start out with a WOA and then grow into SOA.
Labels: Java EE, Web services
11 Comments:
Wow, amazing clarity.
Very to the point comparison, nice blog
Categorization of difference is very useful. Nice blog
Very good comparison. Can you change the font of the content in the table, its so grayed...
good one
Nice information. Thanks.
Thank you :))
Point-by-point comparison in lucid fashion. Thanks a lot.
Though REST generally supports HTTP(S) protocol, in principle RESTful API has multi-protocol support (for example in Restlet framework).
Any comments on this please?
I think the latest Restlet API supports multiple protocol because REST can be defined from a wsdl. Earlier this was not
possible. So in order to support wsdl 2.0 spec, Restlet API also now supports multiple protocol.
Good to know. Thanks for the info Unni.
Wow Nice Explanantion
Post a Comment
Subscribe to Post Comments [Atom]
<< Home