Menu
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
338
REST is a better choice for simple, CRUD-oriented services, because of the way REST repurposes HTTP methods (GET, POST, PUT, and DELETE). It is also popular because it's lightweight and has a smaller learning curve. SOAP, on the other hand, has standards for security, addressing, etc.
REST allows a greater variety of data formats, whereas SOAP only allows XML. Coupled with JSON (which typically works better with data and offers faster parsing), REST is generally considered easier to work with. Thanks to JSON, REST offers better support for browser clients.
Developing public APIs: REST APIs are considered easier to use and adopt than SOAP APIs, which makes them ideal for creating public web services. REST also lacks some built-in security features that SOAP has — but they aren't necessary when working with public data and services.
REST is faster than SOAP because of the involvement of JSON (which is light-weight) in the request/payload of REST. Each method is processed independently in REST which is the reason why it is called “stateless” architecture.
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.
108
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
