Comments on: REST vs. SOAP – The Right WebService

By: Raftian

Raftian — Wed, 26 Oct 2011 09:59:00 +0000

Great article indeed, atleast now I have a fairly good idea of which way to go when I want to expose my underlying data to external apps made by other guys. Don’t know if you have this article on another website, if not, then someone just ripped it off and put it up as theirs. The url where you can get this same article is http://greatgandhi.wordpress.com/2010/06/16/soap-vs-rest-%E2%80%93-the-best-webservice/

By: Lamu_36

Lamu_36 — Mon, 12 Sep 2011 04:06:00 +0000

Sorry for the inconvenience, I know where I can find an example of using RESTful web services and SOAP, but the example is the same

By: morph

morph — Sat, 22 Jan 2011 20:07:00 +0000

I would use restful web service if i have to expose a resource in an efficient way for example if i am hosting a image hosting, file hosting because caching can easily be enabled on rest based service, But when it comes to exposing my complex business methods SOAP based web services are still far better because it has a standards document WSDL which helps in specifying the contract that an end user can understand easily and hence the client code can be written with ease against it.

By: Kingwulf

Kingwulf — Tue, 30 Nov 2010 07:31:40 +0000

You are missing the client generation part of it. Without it WSDL is hardly useful.

By: Yohoboyo

Yohoboyo — Fri, 05 Nov 2010 04:43:05 +0000

You are not the author of this post. It is a blatent plagiarism of other websites.

http://www.devx.com/DevX/Article/8155
http://www.petefreitag.com/item/431.cfm

By: Elvis

Elvis — Wed, 27 Oct 2010 02:39:24 +0000

Actually, I don't think it should be "to view it", if you pay attention to the punctuation.

"You can get the contents of that object using an HTTP GET," => The comma indicates end of subsentence
"to delete it, you then might use a POST, PUT, or DELETE to modify the object." => This is a new subsentence.

However, I do agree that the comma, in addition to "to delete it" before the request types and "to modify the object" causes some confusion.

Personally, I would replace the comma, and leave "to delete it" out all together, like this:
"You can get the contents of that object using an HTTP GET. You then might use a POST, PUT, or DELETE to modify the object (...)"

Also, it would've been decent to mention part of it came from http://www.petefreitag.com/item/431.cfm .

Otherwise, nice article!

By: Dave

Dave — Sat, 23 Oct 2010 11:17:06 +0000

I think you're ignoring one of the major benefits of the SOAP model, namely the contract you get when with the WSDL. It's important for clients to understand exactly what your services support. Relying on human produced documentation is risky at best, whereas an auto generated WSDL will always give you an accurate description of the services. And when the services interface changes, your clients will know because they will start getting errors. None of that happens with REST. If you make an contract breaking change, you have to notify (or try to notify) everyone who uses the service and then they have to pour over the documentation to try to figure out how to recode the client. With a WSDL it's obvious how the client works. An code generation tool can give you a nice object tree with all the types and methods cleanly described. Now THAT'S simple.

Yeah REST is the technology dujour, but a lot of the arguments I see for it fail to give SOAP the props it deserves.

By: Ionut

Ionut — Wed, 01 Sep 2010 12:50:09 +0000

One small typo (I think).. In the following paragraph:

"Representational State Transfer or REST basically means that each unique URL is a representation of some object. You can get the contents of that object using an HTTP GET, to delete it, you then might use a POST, PUT, or DELETE to modify the object (in practice most of the services use a POST for this)."

"to delete it" should be "to view it"

By: Plagiarism

Plagiarism — Thu, 26 Aug 2010 08:24:35 +0000

This article plagiarizes this website:

http://www.petefreitag.com/item/431.cfm

Shameful

By: nnan

nnan — Tue, 17 Aug 2010 17:34:16 +0000

And the world is not just a few HTTP action words. I developed many SOAP projects. It takes a couple of minutes to configure or copy and paste old ant code, then I go off doing my things, don't have to worry about the transport layer. Even better, I works with API just like my code. Not all those states the REST crowd are trying to promote. I think one main problem with SOAP is that it can be extremely easy to develop with some Ant script and Apache axis. However, people don't know how that, and gets into problem. Also, stick with doc/lit, and mostly you'll be fine. The one most important point the author miss is that the transport layer should be as transparent as possible. With SOAP, I can go on quickly without worry about it at all. Basically, I don't develop SOAP most of the time, because why on earth I need to do that? I just develop my business logic. SOAP was done in a couple of minutes, and no longer needed until I need to update (which is extremely quick and simple too).

By: Kailash

Kailash — Fri, 25 Jun 2010 23:13:15 +0000

Very nice article, thank you!

By: adr

adr — Fri, 21 May 2010 06:06:00 +0000

http://www.petefreitag.com/item/431.cfm

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