Using SOAP and REST

Question

I have used SOAP service successfully.

Suppose there is a Web Service that exposes a method that returns the list of Students.

public Student[] listAllStudents(){
  //some code that return Student array
}

Using SOAP will need these steps:

1. Get the URL for the location of WSDL.
   eg. http://127.0.0.1/web/service/location/soap.php?wsdl
2. Use some available technologies like axistools-maven-plugin to generate all stub classes. There will be a generated class with the name like Student

3. Use the appropriate stub class/interface to invoke the service.

   Student[] students = theStub.list_All_Students();

Using REST service will be something like this.

1. Get the right url for getting list of Students.
   eg. http://127.0.0.1/web/service/student/list?sort=true
2. Use some URL Connection techniques like java.net.HttpURLConnection to get the result which is usually in JSON format.
3. Parse the result.

As a Java programmer, I have no problem in using SOAP because there are frameworks designed for it. Moreover, there is only one URL that I need to know for hitting the Web Service.

Using REST is a bit confusing. I need to know all the specific URLs along with the query string required to be passed. From this point of view using REST is quite cumbersome.

My Questions:

1. From the programmer's perspective, is using REST useful at all?
2. Is there any good framework that will make hitting REST easier?

Answer 1

1. From the programmer's perspective, is using REST useful at all?

REST is definitely useful. It's a different way of utilizing web services, compared to what you're used to in SOAP. Here's a quick comparison:

In the end, they each serve their own purpose in the service-oriented world. SOAP is mature but bloated. REST is relatively younger, but is a more natural fit with HTTP. It has huge potential, especially when service contract standards are put into place. When WADL matures, it will boost the popularity and adoption of REST.

2. Is there any good framework that will make hitting REST easier?

A lot. Here are some of the known REST frameworks, with the popular ones being JAX-RS, Jersey, RESTEasy and Restlet.

Answer 2

This is quite an open ended question, but REST is much more interoperable, not to mention the sheer amount of metadata in each query makes it hardly light weight. Consider if you had to query a SOAP endpoint in javascript, or even php can be a pain in the ass. SOAP uses a contract first mechanism that's really suited when you want to consume it using something like c#.

On your second question, yes, you can parse the RESTful response with either Jackson (only for JSON), RestController in Spring, or JAX-RS.

Answer 3

From programmers perspective, yes I think REST is helpful. REST is said to make "complete" use of web, because it unlocks the web potential by using more HTTP methods than before - 'GET', 'POST', 'DELETE', 'PUT'. Otherwise we mostly use 'GET' and 'POST'. I like to think it this way, we any how have to use HTTP to talk to webservice in real world they why not make use of feature which HTTP provides. Till now (before usage of REST) HTTP was a "dummy" (don't take dummy seriously) protocol from programmers perspective just sending my packet and receiving my packets. One fine day HTTP comes to the programmers community and say "Hey! I do have 'DELETE' and 'PUT'. Do you want to simplify your webservice by using them?"

Wikipedia

 REST uses these operations and other existing features of the HTTP protocol. 
 For example, layered proxy and gateway components perform additional functions 
 on the network, such as HTTP caching and security enforcement.

One of the advantages of SOAP over REST is that it works with non-stateless protocols such as TCP, message queue. REST operates on stateless protocol such as HTTP. Because HTTP being more ubiquitous REST seems to be mainly used with HTTP.

With respect to your question on frameworks for REST - I have used JAX-RS and heard Jersey are both equally good selections.

Hope this helps!

Answer 4

REST is more suited for web applications / end user applications. It is more lightweight. It is also designed for the web. Doing true REST is not so simple (you may search on this).

SOAP is more suited for back office applications / professional. SOAP is more heavyweight / complex / secure / contract first / complete / permits to manage transactions.

From a java developer stand-point, having done both, REST is a lot easier to implement / integrate, thanks to JSR-311 capable stacks like Jersey and Resteasy. And yes, Jackson is a great tool.

Seen on twitter today :) :

if you hate someone, endorse them on linkedin for SOAP APIs and waterfall methodologies

8:22pm · 3 Apr 13 · Twitter for iPhone

Answer 5

This question is actually a duplicate of this question, and believe me, trust the most rated answer.

SOAP is not simple and inter-operability is not what it claims to be (attributeFormDefault, RPC/encoded vs Document/literal, etc...). If for REST you need to know URLs, for SOAP you need to know what operation to call.

If you can choose, stay away from SOAP. Save our souls, let SOAP die.

EDIT

With JAX-RS and great stacks like Jersey, Restlet,.. for the REST part, Jackson, XStream, etc.. for the JSON part, doing REST services is simply a few annotations away.