I Have gone through various sites and the only answer they provide is - Restful webservices makes use of Http's own methods such as (GET,POST,PUT,DELETE).. Whereas SOAP based webservices makes use of its own custom methods.. - Restful web services treats each service method as a resource and gives it a URI..
However I do not understand the full significance of these answers.. As to why these things prove to be such a big advantage over SOAP based web services..
An example will be appreciated
REST naturally fits for Web/Cloud API's, whilst SOAP fits for distributed computing scenarios.
Bandwidth is the main benefit of REST, as there is no complex document to traverse (ie XML, SOAP headers), which is extremely important for well performing Web API's. JSON is a widely-recognized and simple standard for data exchange, and is easily read by browsers and client code, which is why most RESTful API's (Yahoo is a good example) offer JSON.
Not to mention REST is available to the XmlHttpRequest object, which again, is crucial for AJAX-ability for Web API's.
And of course the cacheability feature of REST cannot be ignored. Because REST is based on HTTP, it can take advantage of many of the semantics of HTTP (and the web itself), by utilizing headers on the HTTP packets (expires) to enable caching by the browser. Not to mention things like gzip compression to increase efficiency. Performance-wise, REST really nails it over SOAP.
As for SOAP, well SOAP caters for stateful operations. The WS* standard (Security, Transactions, etc) handle this sort of plumbing which is quite common in distributed scenarios. It can be done with REST, sure, but then it wouldn't really be REST. SOAP is really good for defining operational contracts between client and server, which is crucial in distributed scenarios.
So my opinion (and the whole SOAP vs REST thing is highly opinionated), use SOAP for distributed computing scenarios, use REST for Web API's.
The main issue with SOAP is bloat. The more you can do, the less you can use defaults. This leads to huge WSDL downloads even for simple methods. Next, it bloats the parsers (specific parsers are always smaller than general purpose ones), the messages (a whole wad of XML instead of DELETE with a URI), the error handlers (you send 20-30KB of XML to the server and it responds with a 50KB error message; good luck reading and understand it).
Concrete example: The Java code to read a list of documents via SOAP from a SharePoint server is so huge that you need to give the Java compiler 1GB of RAM to compile it.
The same with Restful needs just a few lines of code. On the client, you need to build a request with GET list/some/url. Parsing that on the server will be less effort than compiling WSDL even if you have to write the code by hand.
Many have frowned upon SOAP based web services, due to the extra complexity added by the SOAP layer, considering it as an undue overhead, proposing RESTful web services.
In REST frameworks, the xml message is encapsulated directly in the HTTP payload and not inside a SOAP envelope (same as AJAX).
That reduces the parsing overhead significantly.
But in real cases there is often need to send to server/client extra information not related to the actual xml message payload.
This leads to find ways to transfer the information via the HTTP message.
Since there is the need to transfer such info some have counter-argued that SOAP-based services, facilitate for thesed needs.
The advantages are tactical - its certainly possible to do everything you can do with one in the other, but webservers were here before SOAP and are fairly straightforward to configure so are often simpler. For example, the authentication and such can often be handled by the webserver, as can redirects and load balancing and things. Normal SOAP frameworks don't really have all as complete a set of such things, and can cause growing pains.
