REST vs SOAP Web Services

Published on August 03, 2005
By Pete Freitag

I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one. Lets step back a second and explain what REST is.

What is a REST Web Service

The acronym REST stands for Representational State Transfer, this 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).

Who's using REST?

All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.

Who's using SOAP?

Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.

REST vs SOAP

As you may have noticed the companies I mentioned that are using REST api's haven't been around for very long, and their apis came out this year mostly. So REST is definitely the trendy way to create a web service, if creating web services could ever be trendy (lets face it you use soap to wash, and you rest when your tired). The main advantages of REST web services are:

Lightweight - not a lot of extra xml markup
Human Readable Results
Easy to build - no toolkits required

SOAP also has some advantages:

Easy to consume - sometimes
Rigid - type checking, adheres to a contract
Development tools

For consuming web services, its sometimes a toss up between which is easier. For instance Google's AdWords web service is really hard to consume (in CF anyways), it uses SOAP headers, and a number of other things that make it kind of difficult. On the converse, Amazon's REST web service can sometimes be tricky to parse because it can be highly nested, and the result schema can vary quite a bit based on what you search for.

Which ever architecture you choose make sure its easy for developers to access it, and well documented.

An Update in 2020: When this article was written fifteen years ago, SOAP still had a strong base of support, though it was quickly loosing ground to REST. Things like the popularity of things like Ruby on Rails put a fire under REST (by making it really easy to create REST api's). In the end I think SOAP was just too verbose and slow, REST was something that developers didn't need a library to consume and parse, while if you used SOAP you would not attempt to write a raw implementation from scratch. This developer agility I think led to REST being the winner here over time.

rest soap api web services architecture

REST vs SOAP Web Services was first published on August 03, 2005.

If you like reading about rest, soap, api, web services, or architecture then you might also like:

Discuss / Follow me on Twitter ↯

Tweet Follow @pfreitag

Comments

I think in your REST vs SOAP section you meant that the first list was advantages of REST, not SOAP. Otherwise, great overview of the two technologies.

I would add as an advantage of REST, though, that it's built "closer" conceptually to existing technologies, so in my experience it's more hackable in the sense of combining disparate parts together in innovative ways.

by Patrick on 08/03/2005 at 11:58:50 AM UTC

Patrick, and Ken - yes I meant to say REST not SOAP. I have edited the entry. Thanks!

by Pete Freitag on 08/03/2005 at 12:38:08 PM UTC

I don't want to edit this entry again, but I should have mentioned PayPal as another big user for SOAP, their new web services use SOAP.

by Pete Freitag on 08/03/2005 at 12:40:17 PM UTC

Is there an example of an implementation of a web service using cf7 using rest. I can't seem to find one. I need to expose a web service that will allow for HTTP POST AND GET for consuming.

Thanks
-Luis

by Luis on 07/21/2006 at 9:18:06 AM UTC

I like much on the concept of REST, but can you list a URL that has sample web service implementation using REST.

by Rogelio Carrillo Jr. on 07/17/2007 at 1:49:40 AM UTC

I am an enterprise architect and soa-integration practitioner currently working in MN for a client's transformation from web 1.0 to web 2.0 in which a hybrid Rest Web Services and SOAP services are architectured in two front - web site activites (REST) and (SOAP) enterprise applications interation (EAI) to enterprise information integration (EII)

by JZ on 11/20/2007 at 8:28:13 AM UTC

Where can I find tutorial or complete sample code to build REST WebServices in C#?

by imei on 01/14/2008 at 8:19:31 PM UTC

I think no need to have a competition between REST and SOAP.If you use Apache Axis2c you can use both.When you see some service which is reliable with REST you can use REST and if you see any advantage with SOAP you can use SOAP.

by Lahiru Gunathilake on 02/08/2008 at 8:02:21 PM UTC

Yes, this was a nice overview of the two Web Service types. If you are interested in creating AJAX applications (simple and fast) WaveMaker will consume either of them and are equally easy to wire up to your widgets visually.

by Craig Conover on 04/04/2008 at 1:01:46 PM UTC

Great article Pete. It gives nice overview of both REST and SOAP WS.

And thnx Ed for the article on creating REST WS in C#

by Vijith on 05/03/2009 at 9:50:26 PM UTC

Todd...
REST does have a description language options - HTML Form, WSDL 2.0, or WADL.

See:
http://createtank.com/2009/02/a-web-service-description-for-rest/
http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
http://plasmasturm.org/log/460/
http://en.wikipedia.org/wiki/XForms#XForms_as_part_of_the_XRX_Application_Architecture

by j03 on 10/27/2009 at 4:25:44 PM UTC

what about xml-rpc? you should compare these three to give us basic differences. I heard, xml-rpc is easier for small job. Great article indeed.

by kodegeek on 12/21/2009 at 4:56:45 AM UTC

One of the nice advantages of REST is that it supports the idea of multiple representations for resources: HTML if you look at it with a browser, JSON if you access it with a client application, etc.

Someone here asked for a sample REST web service. I would go here: http://3.ly/restxdemo. It demonstrates RESTx - an open source project for the creation of RESTful web services, home page: http://restx.mulesoft.org. RESTx introduces a whole new concept in which RESTful web services can be created and consumed.

by Juergen Brendel on 09/23/2010 at 1:17:06 PM UTC

I'm always surprised when comparisons don't include WSDL as a SOAP advantage. REST has no description language.

by Zubaer khan on 01/11/2011 at 8:39:54 AM UTC

Google uses REST a lot specifically for mobile - Android. Android SDK does not have support for SOAP services. Google uses and recommends REST/JSON based web services

by Jay Khimani on 06/23/2011 at 6:05:43 AM UTC

Things are constantly changing but things somehow remain the same. As the Bible says "There is nothing new under the sun". I'm an old timer the cut my teeth in programming during the old C and C++ days. We were attempting to figure out how to integrate Unix with the Mainframe with all it's different OS's (VM, MVS, CICS, etc). Because the applications had no public API's only menu driven UI's there was the critical need to integrate with these dinosaur applications (and of course there still is for those of you that think the entire software universe is the content within an HTTP payload). IBM of course created LU6.2 which was a peer to peer protocol that enabled data to be transferred a client application and a mainframe application say in CICS. Well they also had what was known as LU2 which was based on what was known as a 3270 presentation space payload that was functionally similar to an HTTP payload. It contained presentation data based on what fields were on the menu screen and what data was fixed or static. It was all accessible and the fields were writeable, and the static or fixed data was readable. Because it was an an old text based screen, everything was based on rows and columns of a two dimensional presentation space. Elemenets of the screen could be found or written to based on rows and columns and pattern matching. The API that did this was called HLLAPI. I implemented the functional library for HLLAPI for IBM'S

by rolandtrv on 09/11/2011 at 11:44:15 PM UTC

Some how or another my message from the last one got sent before I finished it. Must'a hit a wrong key or something. Getting OLD! Never the less the API library I implemented for IBM was call HLLAPI for IBM's old RS6000 UNIX workstation called of course AIX. But to make a long story short. LU2, 3270, and HLLAPI were nothing more then what was called at that time SCREEN SCRPERS (I had to leave the 'A' out because the site complained about the word R*PE in it). They had the ability to search and write on the screen. Software written in C and C++ could be written relatively quickly while we waited for LU6.2 to become functional. Again they were quick and relatively easy, but they were some what unreliable because of unforseen or unknown error screens thay could mess up the searching and writing for and to proper fields within the screen (the 3270 payload). Also software written with HLLAPI were subject to whimsical screen changes of the developer who was maintaining the program on the Mainframe side. If any changes to the screen ocurred that were not communicated to those that needed them to be the same would break your software. Today with REST, if you are interfacing with a public application on the web (through the browser) you too are subject to the whimsical changes that web site applications always do. Now of course most of the REST applications that are written by the owners of the web site who insure any REST application dependent on them know the changes so that they can update the REST application. The peer to peer protocol LU6.2 was considered much better because it was easier to maintain changes and was faster. Never the less they were more difficult to develop because they were normally much larger and much more complicated. SOAP web services with WSDLs is more akin to the old LU6.2 because it invokes a service in the cloud that returns data within an XML payload defined by the WSDL. So SOAP web services are more sophisticated (in the backend) and can do more because they directly integrate with the databases and other resources within the cloud. So to say REST should be used over SOAP is a misunderstanding of the functionality of the two types of interfaces. REST does not have direct accessibility with the backend making it a completely different utility then SOAP.

by rolandtrv on 09/12/2011 at 12:19:52 AM UTC

I think there is generally being looked and thought wrongly about the two methods SOAP (Simple Object Access Protocol) and RESTful(REpresentational State Transfer) - web services.
The reason REST has gotten so popular is that it has an ALTERNATIVE to what SOAP has to offer when it comes to making web services quick and easy.
You can think of the 2 methods like this:
-SOAP being a letter made of an envelope(the container), address field(who is to receive the letter) and the body (the contents inside the letter). This means you cant see what is in a SOAP message until opened.
-RESTful being a post-it where you write the contents on it and slam it up in the left upper corner of the billboard and tell people about it. Now you can't have one post-it going on top of another, meaning that RESTful web services needs a unique URI(link).

This was just a bit about the subject. The main conclusion is that you should think of REST as an alternative to SOAP, being more easy, faster and less complicated than SOAP is to create. At least that is how it is at the moment. As far as i know, Oracle and Microsoft are trying to come up with a solution...

by Simon on 05/25/2012 at 12:57:08 PM UTC