1

Folks I recently went thru webservices book which covered SOAP based webservices and RESTful webservices. I am not sure on what parameters I should select one of them as both of them looks similar(even from developer perspective). Here are my points

In SOAP webservices we use WSDL file generated out of webservices and then create client side stubs based on that.

My understanding is that internally stub also will use HTTP protocol to communicate with remote java webservice. Right?

Here there will be SOAP message(XML message) inside HTTP request/response body. so one more layer to drill down while in REST based webservices, HTTP request itself behave as messages. Here we have WADL instead of WSDL. Here also we can create the stubs based on WADL. So every things looks more or less same except the some technical difference consumer connect to producer and how request/reponse are processed.So as per my understanding there is not much difference b/w rest based and soap based webservices from developer point of view (amount of work for developer is almost same).

Is my understanding correct?

Yes probably behind the scenes, probably SOAP is more complicated than REST webservices becoz in SOAP, there is messages inside message(SOAP message is embedded inside HTTP request) but in REST based services, HTTP request itself works as message.

Uwe Plonus
  • 9,803
  • 4
  • 41
  • 48
M Sach
  • 33,416
  • 76
  • 221
  • 314

3 Answers3

3

SOAP and REST are aimed at solving a identical set of problems, namely facilitate the interaction between heterogeneous applications in easiest possible manner. Now whether to choose REST or SOAP does not just depend on the amount of development effort. You should consider some of following factors as well,

  1. The type of data whether its just simple objects (like name value pair) or very complex schema (or some binary data) to be exchanged between the applications.
  2. The consumer of your service. E.g. REST are more suitable when you are developing RIA.
  3. Security requirement. SOAP by virtue of being standard driven, offers a very fine grain level tuning of security aspect. You can go to an extent of encoding the individual elements of your SOAP xml message. These type of things are not possible in REST (at lest for now).
  4. Nowadays notations like JSON are quite popular for lightweight data exchange and many REST service frameworks offers this very easily out of box.
  5. Technically, you do not need any framework etc to create a REST web service. I understand that WADL etc came recently to bring in an element of standardization but REST existed even before WADL came. REST is nothing new, its the way web works. REST frameworks make it very easy.

SOAP is driven by standards and hence there are more constraints to honor when you work with them. So if you use case is simple (well that's very subjective), go for REST.

Minko Gechev
  • 25,304
  • 9
  • 61
  • 68
Santosh
  • 17,667
  • 4
  • 54
  • 79
  • Santosh as you said "REST existed even before WADL came". My question here is without WADL (or some other description )how consumer will know what are the operations exposed on producer side? There should be some description of produced webservices so that consumer can target the intended one. Right? – M Sach Jul 20 '13 at 10:40
  • I think another major differnce i found is, in REST data( whether its xml,json,string) travels as name value pair and we do not have to generate the stubs/skelton while in soap based webservice, we data is travelled as XML message under soap envelop which resides under body of http message.Also we need stub/skelton here for inter-operability. Is that right? – M Sach Jul 20 '13 at 10:54
  • @MSach WADL came to bring in an element of standardization and it has more to do with offering tooling assistance(_generating stubs etc_) than anything to do with REST per se. At core, REST is nothing but the the way web work. You specify a resource with and plain simple URL. Before WADL, you just invoke the web service by passing some parameter and see the output, OR the service provider offers a detailed documentations for each service example [Google APIs](http://googlesystem.blogspot.in/2008/04/google-search-rest-api.html). – Santosh Jul 20 '13 at 15:42
  • @MSach, regarding the difference you mentioned, yes, that's true we always send data as HTTP form methods (GET/POST etc). But the response could be anything including JSON, a simple Text or a complex XML tree. REST does not limit you with that and that's the beauty and strength of it. This is the very reason that they are so popular for simple use cases. Regarding inter-operability REST is also inter-operable. You see everything REST uses is platform independent. The HTTP, JSON, XML, etc all technology/platform neutral standard. – Santosh Jul 20 '13 at 15:51
1

These are two different ways to develop web services... and there is a lot of discussion about their differences (and advantages).

SOAP web services are much more than the points you refer, actually there is a complete "stack" (WS-*) that aims at standardizing ways to design and implement such web services. This is nice for some systems, but it is "too much" and heavy for others. Behind the scenes HTTP is one popular way to "transport" messages, but it is not the only one, they could be implemented over other protocols. In SOAP you heavily rely on the "WSDL" specification, which indeed can be used to "generate" server and client code. In these specification you think very much about "operations", things to be done on the web service.

On the other hand on REST we think more about "resources" (described by a given URI), and then over it we perform the HTTP operations. There is not so much the notion of specification as in SOAP web services, although WADL exists. Actually a big difference, and which people do not think much about (but actually is part of the core of REST principles), is the idea that in REST you have the so called "hyperlinks", which aim at allow client-server to communicate "state" (where to go next), which is not so "dynamically" handled in SOAP web services.

Bottom line, for developers point of view: SOAP does have quite a lot of good tooling (e.g.: all Eclipse Web services tools), however it tends to be a bit cumbersome and a lot of "code". REST development is normally cleaner and simpler. I do think both are solutions that be used as function of the situation you are dealing with, you should not "pick one". For example, if you have a huge enterprise applications, with a lot of parts and interdependencies, transactions handling, etc., probably SOAP Web services with WSDL (contracts) is the way to go. On the other hand if you are exposing one web service (or API) to clients, without many interdependencies, probably REST is the most interesting (you can see this in the changes we got on the last 5 years or so, where all major Web APIS - google, twitter, etc., all are now exposed as REST web services).

emgsilva
  • 3,047
  • 1
  • 17
  • 16
  • As you said "SOAP tends to be a bit cumbersome and a lot of "code". REST development is normally cleaner and simpler". My point is both seems equally cumbersome and involves almost equal amount of code. Can you explain you statement bit in detail. Thanks in advance. – M Sach Jul 16 '13 at 06:58
  • I meant: in WSDL you normally generate a lot of code (skeletons and stubs) to handle the communications of the web service. In REST (e.g.: using Jersey in Java) you have your server code, e.g.: API resource, handled by a Java method on a class, and you add a simple annotation to the method to expose it in your API, and that is pretty much it (see this hello world example of Jersey: http://www.mkyong.com/webservices/jax-rs/jersey-hello-world-example/). That was why I mentioned it tends to be cleaner. But again, in some situations SOAP Web services may be better suited. – emgsilva Jul 16 '13 at 07:12
0

There are no big differences (especially from developers view).

The only real difference is that SOAP is standardized with the WS-* recommendations. Also in SOAP there are possibilities to create transactions and to secure the message itself based on the standards. So for interoperability SOAP has advantages based on this.

Uwe Plonus
  • 9,803
  • 4
  • 41
  • 48