Java Reference
In-Depth Information
simple answer to this question. You must weigh a number of factors that are application-
specific. To start with, is your application already using exposing functionality via either
SOAP or REST? If not, how well do the services map to either REST or SOAP? REST is
much more stringent in terms of how the API should be structured. What types of clients
are you expecting, and do you need to provide a self-documenting WSDL file so code can
be auto-generated?
Popularity of a particular approach often factors into the decision. Currently, REST is the
more popular approach for creating new web services. SOAP is complex and has signi-
ficant overhead. This overhead and complexity often get in the way and make exposing
simple services needlessly complex. As a result, REST is a “back to the basics” approach.
REST's popularity has risen as a result of extremely popular RESTful services provided
by Amazon, Flickr, and Google. If you're not locked into one approach or are considering
switching, we'll look at the benefits and trade-offs of each.
Let's start with SOAP. A few of the chief benefits of SOAP are that it's self-documenting
and has excellent tooling support, and there are multiple WS specifications that extend
SOAP by adding layers for reliable messages, transactions, and security, among others.
The self-documenting nature of SOAP through complex XML documents has resulted in a
myriad of point-and-click tools that can auto-generate and invoke web services. A business
analyst or system integrator can thus use a web service without necessarily understanding
how the SOAP service works and what's happening under the hood. On the flip side, if
you don't have good tools or don't know how to effectively use them, editing WSDL doc-
uments (if not using auto-generation) will be laborious. Because there's an emphasis on
tooling and auto-generation, you must be aware of the limitation of the tools when support-
ing multiple platforms and how they interpret XML schema when generating code.
SOAP-based web services also support the ability to be routed through intermediate nodes.
Each node can inspect the header, perform an operation, and then forward the message.
This is a useful feature in complex environments.
REST is fairly simply: each REST operation maps to a URL and the HTTP method de-
termines the type of operation performed. A RESTful web service should map to a CRUD
operation. You must put thought into the HTTP method as well as the structure of the URL.
The output from a RESTful web service doesn't need to be XML—it could be JSON, text,
an image, and so on. Query parameters are used to pass parameters to the service. With the
ability to use query parameters and return compact output, such as JSON, RESTful web
