Recently, I decided to start learning about java web services and when I started to search a tutorial

for java web-services in google, I found out that there are many types of webservices XML based,
SOAP based, also RESTful webservices.

Also, I found that there is a JAX-WS specification for xml based web-services, and JAX-RS
specification for creating RESTful webservices.

Q1) I got confused, it would be great if anybody can help me understanding the difference between
these different type of webservices, so that I can decide which one to learn first.

Q2) Also, I want to learn in-depth about creating different types of web-services in java. Is there any
tutorial or resources which can give an insight to each kind of webservice and a comparison
between them.

Q3) based on what scenarios and conditions should I decide that I want to create an xml based web-
service rather than a SOAP service or I should go with RESTful service.

Thanks a lot in advance, your opinions and suggestions would be very helpful for me.

------------------

1. SOAP Web Services are standard-based and supported by almost every software platform:
They rely heavily in XML and have support for transactions, security, asynchronous messages
and many other issues. It’s a pretty big and complicated standard, but covers almost every
messaging situation. On the other side, RESTful services relies of HTTP protocol and verbs
(GET, POST, PUT, DELETE) to interchange messages in any format, preferable JSON and
XML. It’s a pretty simple and elegant architectural approach.
2. As in every topic in the Java World, there are several libraries to build/consume Web
Services. In the SOAP Side you have the JAX-WS standard and Apache Axis, and in REST you
can use Restletsor Spring REST Facilities among other libraries.
With question 3, this article states that RESTful Services are appropiate in this scenarios:
 If you have limited bandwidth
 If your operations are stateless
 If your clients require caching.
While SOAP is the way to go when:

 If you require asynchronous processing

The SOAP WS supports both remote procedure call (i.e. RPC) and message oriented middle-ware
(MOM) integration styles. The Restful Web Service supports only RPC integration style.

The SOAP WS is transport protocol neutral. Supports multiple protocols like HTTP(S), Messaging,
TCP, UDP SMTP, etc. The REST is transport protocol specific. Supports only HTTP or HTTPS
protocols.
The SOAP WS permits only XML data format.You define operations, which tunnels through the
POST. The focus is on accessing the named operations and exposing the application logic as a
service. The REST permits multiple data formats like XML, JSON data, text, HTML, etc. Any browser
can be used because the REST approach uses the standard GET, PUT, POST, and DELETE Web
operations. The focus is on accessing the named resources and exposing the data as a service.
REST has AJAX support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create,
Read, Update, and Delete) operations. GET - represent() POST - acceptRepresention() PUT -
storeRepresention() DELETE - removeRepresention()

SOAP based reads cannot be cached. REST based reads can be cached. Performs and scales
better. SOAP WS supports both SSL security and WS-security, which adds some enterprise security
features like maintaining security right up to the point where it is needed, maintaining identities
through intermediaries and not just point to point SSL only, securing different parts of the message
with different security algorithms, etc. The REST supports only point-to-point SSL security. The SSL
encrypts the whole message, whether all of it is sensitive or not. The SOAP has comprehensive
support for both ACID based transaction management for short-lived transactions and compensation
based transaction management for long-running transactions. It also supports two-phase commit
across distributed resources. The REST supports transactions, but it is neither ACID compliant nor
can provide two phase commit across distributed transactional resources as it is limited by its HTTP
protocol.

The SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP
intermediaries. REST does not have a standard messaging system, and expects clients invoking the
service to deal with communication failures by retrying.

REST vs SOAP Web Services

What is a REST Web Service

The acronym REST stands for Representational State Transfer, this basically means that each
unique URL is a representation of some object. You can get the contents of that object using an
HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in
practice most of the services use a POST for this).

Who's using REST?

All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines,
technorati, and both eBay, and Amazon have web services for both REST and SOAP.

Who's using SOAP?

REST vs SOAP

As you may have noticed the companies I mentioned that are using REST api's haven't been around
for very long, and their apis came out this year mostly. So REST is definitely the trendy way to
create a web service, if creating web services could ever be trendy (lets face it you use soap to
wash, and you rest when your tired). The main advantages of REST web services are:

Lightweight - not a lot of extra xml markup Human Readable Results Easy to build - no toolkits
required SOAP also has some advantages:

Easy to consume - sometimes Rigid - type checking, adheres to a contract Development tools For
consuming web services, its sometimes a toss up between which is easier. For instance Google's
AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a
number of other things that make it kind of difficult. On the converse, Amazon's REST web service
can sometimes be tricky to parse because it can be highly nested, and the result schema can vary
quite a bit based on what you search for.

Which ever architecture you choose make sure its easy for developers to access it, and well
documented.