Thursday, September 18, 2014

Compare RESTful vs SOAP Web Services

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.





 Compare RESTful vs SOAP 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

No comments:

Post a Comment