SOAP relies on XML (Extensible Markup Language) in
three ways; the Envelope – that defines what is in the message and how to
process it, a set of encoding rules for data types, and finally the layout of
the procedure calls and responses gathered. This envelope is sent via a
transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed and the
envelope is returned with information in a XML formatted document.
It is important to note that one of the advantages
of SOAP is the use of the “generic” transport. While REST today uses
HTTP/HTTPS, SOAP can use almost any transport to send the request, using
everything from the mentioned to SMTP (Simple Mail Transfer Protocol) and even
JMS (Java Messaging Service). However, one perceived disadvantage is the use of
XML because of the verboseness of it and the time it takes to parse.
However, the good news for web developers is that
both technologies are very viable in today’s market. Both REST and SOAP can
solve a huge number of web problems and challenges, and in many cases each can
be made to do the developers bidding, which means they can work across the
domain.
But the untold story is that both technologies can
be mixed and matched. REST is very easy to understand and is extremely
approachable, but does lack standards and is considered an architectural
approach. In comparison, SOAP is an industry standard with a well-defined
protocol and a set of well-established rules to be implemented, and it has been
used in systems both big and small.
So this means areas that REST works really well for
are:
- 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 it. (Communication between clients and
servers must be stateless: servers should not store any information about
the context of clients between calls, with the exception of session information
that is used to maintain authentication).
- Caching
situations; if the information can be cached
because of the totally stateless operation of the REST approach, this is
perfect.
That covers a lot of solutions in the above three.
So why would I even consider SOAP? Again, SOAP is fairly mature and
well-defined and does come with a complete specification. The REST approach is
just that, an approach and is wide open for development, so if you have the
following then SOAP is a great solution:
- Asynchronous
processing and invocation; if your
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.
- 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.
As shown above, each technology approach has their
uses. They both have underlying issues around security, transport layers, and
the like, but they both can get the job done and in many cases, they each bring
something to the web. So for this argument, the best rule, is the rule of
flexibility, because no matter what the problem at least in today’s web
development world, web developers have great solutions using either of these
protocols.
No comments:
Post a Comment