Comments on: REST vs. SOAP – The Right WebService

By: rhoerbe

rhoerbe — Sun, 21 Feb 2010 23:54:08 +0000

“Google is consistent in implementing their web services using SOAP” – not true. Most APIs build on Google' Data PI, that is kind of RESTful. The Google SOAP search API was deprecated in 2006.

Binary data is still a problem with SOAP; SwA is no official, MTOM requires binary to base64 converison and back; REST has the capability of using MIME-attachments, but tool support needs to be established.

By: Michael Jiang

Michael Jiang — Fri, 12 Feb 2010 22:40:32 +0000

I have hand on experiences with both REST and SOAP.
I would prefer SOAP in that with today’s SOAP Tool kit, almost all major programming languages can compile WSDL to generate SOAP client library can be a big deal in terms of automation integration.
All the pros and cons that author motioned are correct. REST response is simple and user readable. But wait… Why human want to read the response? There is HTML for human already! The web services mean to system to system (B2B) communication. SOAP is designed for high level automation. Of course it hard for human to read SOAP message (actually not that hard), it is for machine to read!
For SAOP client: Just download WSDL or load WSDL from its url, the tool kits (include JAVA, .NET(C#,VB), PHP, C++, etc) will automatically discovered methods and generates the library for you. You can call the methods presented by the WS server right in the client code no matter what the language you use. You call WS methods without write any code. Furthermore in server side even the WSDL can be auto generated in JAVA, C#, etc. The server side only need implements the methods, and with tools, the client can automatically call those methods. It is that simple for SOAP WS. Plus there are a lot more in SOA, ESB.
For REST: WS methods cannot be auto discovered. The WS provider has to provide client library and has to be well documented on every method. It is a huge effort to create the lib (for all major languages) and synch with its documentation. If WS providers do not have the lib, you have to wait for a community to develop them or you have to develop the lib yourself by the doc. Again the methods are not auto discovered, and easily out of the synch. When you get a “500 Internal Server Error”, you may aware that the APIs changed, but what is the change?
In short, SOAP, high level auto, easy to plug in, easy consuming, SOA enabled. higher overhead. REST, fast. Not easy for sys-sys communicate, but easy for human consuming(why?), not SOA enabled.

By: Mike

Mike — Tue, 15 Dec 2009 20:38:42 +0000

Your article makes a mistake in the statement that says, 'For example, a GET request can always be considered safe because it can’t, by definition, modify any data. It can only query data.'

GETs can indeed modify data, they are just supposed to not modify data. The end resource of whatever the GET points to (the code that ultimately runs) can edit, delete, remove or whatever.

By: Text to Speech API

Text to Speech API — Tue, 15 Dec 2009 16:09:33 +0000

[...] I found that anyone can get access to the service. Basically, what Google is taking a plain HTTP GET (REST) based request and returning the audio in MP3 format, The Request URL [...]

By: Mike

Mike — Tue, 15 Dec 2009 14:38:42 +0000

Your article makes a mistake in the statement that says, 'For example, a GET request can always be considered safe because it can’t, by definition, modify any data. It can only query data.'

GETs can indeed modify data, they are just supposed to not modify data. The end resource of whatever the GET points to (the code that ultimately runs) can edit, delete, remove or whatever.

By: Java EE 6 Features Overview

Java EE 6 Features Overview — Fri, 11 Dec 2009 15:52:35 +0000

[...] REST is increasingly gaining traction as an alternative web services development paradigm. We know of the advantages from REST vs. SOAP [...]

By: Chris

Chris — Fri, 11 Dec 2009 15:46:54 +0000

SOAP has not stood for Simple Object Access Protocol for quite some time now.

By: What is Windows Azure

What is Windows Azure — Tue, 17 Nov 2009 23:45:09 +0000

[...] What app developers and enterprises need to know before signing up for Microsoft’s cloud platform REST vs. SOAP using HTTP – Choosing the Right WebService Protocol So what all can be done with Windows [...]

By: azeroth

azeroth — Sat, 14 Nov 2009 11:08:03 +0000

Isn't your example http://www.ExampleCurrencyBrokerage.com/convert... unRESTful? Isn't REST more about webish CRUD?

Also, who provides the processing of returned data to extract whatever you need? When you use SOAP or XML-RPC, the library does it from you but with REST you're supposed to parse the returned XML manually, right?

By: What You Should Know About VoIP Phones | Intro to SIP Systems

What You Should Know About VoIP Phones | Intro to SIP Systems — Wed, 02 Sep 2009 11:55:27 +0000

[...] REST vs. SOAP using HTTP – Choosing the Right WebService Protocol … [...]

By: Chopper

Chopper — Tue, 25 Aug 2009 08:00:51 +0000

Hi, overall I like the comparison. However, I don’t think that you’ve spent enough (or any) time on the benefits of WDSL. For people working with enterprise web services, the reason that SOAP persists is that WSDL makes it possible to define a service contract in an external document that is readable by 3rd party applications. Until WSDL 2.0 is formalised, that isn’t the case for REST. If you use a tool with a graphical front end (such as Sonic ESB, Aqualogic, Fiorano, etc.), you will see that the big win is that an interface is dynamically created from the WSDL allowing drag and drop mapping data into request parameters and out of the response. This is where SOAP wins hands down at the moment – speed of development using graphical tools.

By: bqlr

bqlr — Tue, 25 Aug 2009 05:40:10 +0000

why not compare them in scalability, REST is better than SOAP