SOAP : Great at Asynchronous processing and invocation, Formal contracts, Stateful operations
REST : Limited bandwidth and resources, Totally stateless operations, Caching situations
SOAP
- SOAP stands for Simple Object Access Protocol. REST stands for REpresentational State Transfer.
- SOAP is a XML based messaging protocol and REST is not a protocol but an architectural style.
- SOAP has a standard specification but there is none for REST.
- Whole of the web works based on REST style architecture. Consider a shared resource repository and consumers access the resources.
- Even SOAP based web services can be implemented in RESTful style. REST is a concept that does not tie with any protocols.
- SOAP is distributed computing style and REST is web style (web is also a distributed computing model).
- REST messages should be self-contained and should help consumer in controlling the interaction between provider and consumer(example, links in message to decide the next course of action). But SOAP doesn’t has any such requirements.
REST
- REST does not enforces message format as XML or
JSON or etc. But SOAP is XML based message protocol.
-
REST follows stateless model. SOAP has
specifications for stateful implementation as well.
-
SOAP is strongly typed, has strict specification for every part of
implementation. But REST gives the concept and less restrictive about the
implementation.
- herefore REST based implementation is simple
compared to SOAP and consumer understanding.
- SOAP uses interfaces and named operations to
expose business logic. REST uses (generally) URI and methods like (GET, PUT,
POST, DELETE) to expose resources.
- SOAP has a set of standard specifications.
WS-Security is the specification for security in the implementation. It is a
detailed standard providing rules for security in application implementation.
Like this we have separate specifications for messaging, transactions, etc.
- Unlike SOAP, REST does not has dedicated
concepts for each of these. REST predominantly relies on HTTPS.
- Above all both SOAP and REST depends on design and
implementation of the application.
Areas
where SOAP based Web Services is a great solution:
Asynchronous
processing and invocation: If application needs a guaranteed level
of reliability
and security then SOAP 1.2
offers additional standards to ensure this type of operation. Things like
WSRM – WS-Reliable Messaging
etc.
Formal
contracts: If
both sides (provider and consumer) have to agree on the exchange format
then SOAP 1.2 gives the rigid
specifications for this type of interaction.
Stateful
operations: If
the application needs contextual information and conversational state
management then SOAP 1.2 has the
additional specification in the WS* structure to support those things
(Security, Transactions, Coordination, etc). Comparatively, the REST approach
would make the developers build this custom plumbing.
Areas
where Restful Web Services are a great choice:
Limited
bandwidth and resources: Remember the return structure is really in any format
(developer defined). Plus, any
browser can be used because the REST approach uses the standard GET, PUT, POST,
and DELETE verbs.
Again, remember that REST can also use the XMLHttpRequest object that
most modern browsers support today, which adds an extra bonus of AJAX.
Totally
stateless operations: If an operation needs to be continued, then REST is not the
best
approach and SOAP may fit it
better. However, if you need stateless
CRUD (Create, Read, Update,and Delete) operations,
then REST is suitable.
Caching
situations: If
the information can be cached because of the totally stateless operation of the
REST approach, this is perfect.
