SOAP vs REST Web Services
There are
many differences between SOAP and REST web services. The important 10
differences between SOAP and REST are given below:
No.
|
SOAP
|
REST
|
1)
|
SOAP is a protocol.
|
REST is an architectural style.
|
2)
|
SOAP stands for Simple Object
Access Protocol.
|
REST stands for REpresentational
State Transfer.
|
3)
|
SOAP can't use REST because
it is a protocol.
|
REST can use SOAP web
services because it is a concept and can use any protocol like HTTP, SOAP.
|
4)
|
SOAP uses services interfaces to
expose the business logic.
|
REST uses URI to expose business
logic.
|
5)
|
JAX-WS is
the java API for SOAP web services.
|
JAX-RS is
the java API for RESTful web services.
|
6)
|
SOAP defines standards to
be strictly followed.
|
REST does not define too much standards
like SOAP.
|
7)
|
SOAP requires more bandwidth and
resource than REST.
|
REST requires less bandwidth and
resource than SOAP.
|
8)
|
SOAP defines its own security.
|
RESTful web services inherits
security measures from the underlying transport.
|
9)
|
SOAP permits XML data
format only.
|
REST permits different data
format such as Plain text, HTML, XML, JSON etc.
|
10)
|
SOAP is less preferred than
REST.
|
REST more preferred than
SOAP.
|
Original Link: http://www.javatpoint.com/soap-vs-rest-web-services
There are currently two schools of thought in developing Web Services – one being the standards-based traditional approach [ SOAP ] and the other, simpler school of thought [ REST ].
This article quickly compares one with the other -
REST
|
SOAP
|
Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries
|
Designed to handle distributed computing environments
|
Minimal tooling/middleware is necessary. Only HTTP support is required
|
Requires significant tooling/middleware support
|
URL typically references the resource being accessed/deleted/updated
|
The content of the message typically decides the operation e.g. doc-literal services
|
Not reliable – HTTP DELETE can return OK status even if a resource is not deleted
|
Reliable
|
Formal description standards not in widespread use. WSDL 1.2, WADL are candidates.
|
Well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy
|
Better suited for point-to-point or where the intermediary does not play a significant role
|
Well suited for intermediated services
|
No constraints on the payload
|
Payload must comply with the SOAP schema
|
Only the most well established standards apply e.g. HTTP, SSL. No established standards for other aspects. DELETE and PUT methods often disabled by firewalls, leads to security complexity.
|
A large number of supporting standards for security, reliability, transactions.
|
Built-in error handling (faults)
|
No error handling
|
Tied to the HTTP transport model
|
Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP
|
Less verbose
|
More verbose
|