Understanding SOAP and REST Basics And Differences

Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) are two answers to the same question: how to access Web services. The choice initially may seem easy, but at times it can be surprisingly difficult.

SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest.

The Difference between SOAP vs REST APIs

REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use.

Before I go any further, it’s important to clarify that while both SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information.

A Quick Overview of SOAP

SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.

After an initial release, Microsoft submitted SOAP to the Internet Engineering Task Force (IETF) where it was standardized. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a whole laundry list of these standards on Web Services Standards.

The point is that SOAP is highly extensible, but you only use the pieces you need for a particular task. For example, when using a public Web service that’s freely available to everyone, you really don’t have much need for WS-Security.

The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML.

Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.

One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work. The error reporting even provides standardized codes so that it’s possible to automate some error handling tasks in your code.

An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports. In fact, developers in some languages, such as Python and PHP, are doing just that.

A Quick Overview of REST

Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.

REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks.

Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.

As an example of working with REST, you could create a URL for Weather Underground. The API’s documentation page shows an example URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json. The information you receive in return is a JSON formatted document containing the weather for San Francisco. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.

Deciding Between SOAP and REST

Before you spend hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both. The focus of your decision often centers on which Web service best meets your needs, rather than which protocol to use.

Soap Vs Rest

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:

  • Language, platform, and transport independent (REST requires use of HTTP)
  • Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
  • Standardized
  • Provides significant pre-build extensibility in the form of the WS* standards
  • Built-in error handling
  • Automation when used with certain language products

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:

  • No expensive tools require to interact with the Web service
  • Smaller learning curve
  • Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
  • Fast (no extensive processing required)
  • Closer to other Web technologies in design philosophy

Locating Free Web Services

The best way to discover whether SOAP or REST works best for you is to try a number of free Web services. Rolling your own Web service can be a painful process, so it’s much better to make use of someone else’s hard work. In addition, as you work with these free Web services you may discover that they fulfill a need in your organization, and you can save your organization both time and money by using them. Here are some to check out:

One common concern about using a free Web service is the perception that it could somehow damage your system or network. Web services typically send you text, not scripts, code, or binary data, so the risks are actually quite small.

Of course, there’s also the concern that Web services will disappear overnight. In most cases, these Web services are exceptionally stable and it’s unlikely that any of them will disappear anytime soon. I’ve been using some of them now for five years without any problem. However, stick with Web services from organizations with a large Internet presence. Research the Web service before you begin using it.

Working with the Geocoder Web Service

To make it easier to understand how SOAP and REST compare, I decided to provide examples of both using the same free Web service, geocoder.us (thank you to Mark Yuabov for suggesting it). This simple Web service accepts an address as input and spits out a longitude and latitude as output. You could probably mix it with the Google Maps API example I present in “Using the Google Maps API to Add Cool Stuff to Your Applications.”

Viewing a Simple REST Example

Sometimes, simple is best. In this case, REST is about as simple as it gets because all you need is an URL. Open your browser—it doesn’t matter which one—and type http://rpc.geocoder.us/service/csv?address=1600+Pennsylvania+Ave,+Washington+DC in the address field. Press Enter. You’ll see the output in your browser in CSV format:

GeoCoder REST example

You see the latitude, followed by the longitude, followed by the address you provided. This simple test works for most addresses in most major cities (it doesn’t work too well for rural addresses, but hey, what do you expect for free?). The idea is that you obtain the latitude and longitude needed for use with other Web services. By combining Web services together with a little glue code, you can create really interesting applications that do amazing things in an incredibly short time with little effort on your part. Everyone else is doing the heavy lifting. You can also test your REST API with simple to use tools like SoapUI.

Explaining a Simple SOAP Example

SOAP, by its very nature, requires a little more setup, but I think you’ll be amazed at how simple it is to use.

Begin this example by creating Windows Forms application using Visual Studio. The sample code uses C#, but the same technique works fine with other .NET languages (you’ll need to modify the code to fit). Add labels, textboxes, and buttons as shown here (the Latitude and Longitude fields are read-only).

GeoCoder SOAP example

Here’s where the automation comes into play. Right click References in Solution Explorer and choose Add Service Reference from the context menu. You’ll see the Add Service Reference dialog box. Type the following address into the address field: http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl and click Go. Type GeocoderService in the namespace field. Your dialog box should look like the one shown here.

GeoCoder Web service

Click OK. Visual Studio adds the code needed to work with Geocoder in the background.

At this point, you’re ready to use the Web service. All you need to do is to add some code to the Get Position button as shown here.

private void btnGetPosition_Click(object sender, EventArgs e)
   // Create the client.
   GeocoderService.GeoCode_PortTypeClient Client =
      new GeocoderService.GeoCode_PortTypeClient();

   // Make the call.
   GeocoderService.GeocoderResult[] Result =

   // Check for an error result.
   if (Result != null)
      // Display the results on screen.
      txtLatitude.Text = Result[0].lat.ToString();
      txtLongitude.Text = Result[0].@long.ToString();
      // Display an error result.
      txtLatitude.Text = "Error";
      txtLongitude.Text = "Error";

The code begins by creating a client. This is a common step for any Web service you use with Visual Studio (or other environments that support SOAP natively). To see another version of the same step, check out the PHP example.

After you create the client, you use it to call one of the methods supported by the Web service. In this case, you call geocode() and pass the address you want to work with. The result of the call is stored in a GeocoderResult variable named Result. A single address could possibly end up providing multiple positions if you aren’t specific enough, so this information is passed back as an array.

Let’s assume that no errors occur (resulting in a null return value). The example assumes that you provided great information, so it places the information found in the first Result entry into the Latitude and Longitude output. So, this example isn’t really that complicated compared with REST, but as you can see, even a simple example is more work.

The Bottom Line: When To Use SOAP Or REST

Some people try to say that one process is better than the other, but this statement is incorrect. Each protocol has definite advantages and equally problematic disadvantages. You need to select between SOAP and REST based on the programming language you use, the environment in which you use it, and the requirements of the application. Sometimes SOAP is a better choice and other times REST is a better choice. In order to avoid problems later, you really do need to chart the advantages and disadvantages of a particular solution in your specific situation.

There’s one absolute you should get from this article. Don’t reinvent the wheel. It’s amazing to see companies spend big bucks to create Web services that already exist (and do a better job than the Web service the company creates). Look for free alternatives whenever possible. In many cases, the choice of Web service also determines your choice of protocol.

Actually there are two. Whether you pick between SOAP or REST for your web service, making sure you thoroughly test your APIs. Ready! API has a full suite of functional, performance, security and virtualization tools for your API testing needs. You can also learn how to test RESTful APIs, in our API Testing Resource Center.

See also:

Photo source: Glyphobet.net


  1. Jason Chaney says:

    You should consider using SOAPUI to show the interaction on the SOAP example. Better to show the SOAP portions but still the code is generated behind the scenes.

  2. p3n15h34d says:

    soap sucks donkeyballs – its one of the best examples of overengineering.
    how could anyone even think of reinventing and overcomplicating everything that works well on the web?
    you’re on the web, so you can use the established protocols like HTTP in the intended manner and take advantage of advanced features like caching, conditional requests, e-tags and more.
    so if you just need some data/resource from a free service, it just shouldn’t take you more than just send a request to the specified URL.

    and wsdl and stuff like this: it seems to be a nice idea, but our machines/AI is not intelligent enough to decide if a service meets the needs, so it’s still the developer who has to work with this.
    yeah great, you can generate classes for accessing the service, but why should you even need it? if you’re using REST you got a universal clients like curl that can work with any service!

    • It’s not always developers. One can use Spring and CXF to auto-generate a client interface from a WSDL with about 4 lines of configuration (less if you don’t want the option of swapping in mock endpoints for testing). SOAP has been around long enough that developers have made open source tools to reduce the pain, but you do have to hunt for them.

      CXF is an interesting example because it allows web services to be built with BOTH REST and SOAP, so you can be indecisive and flexible for your clients, but you also double your maintenance load, hehe.

  3. “SOAP and REST are protocols”, very wrong

    • Thành Nguyễn says:

      who said that “SOAP and REST are protocols” ?

      • this 4th paragraph opener did : ‘Before I go any further, it’s important to clarify that both SOAP and REST are protocols: ‘

        • Nop, it didn’t say they are both protocols. Here is the exact copy:

          “Before I go any further, it’s important to clarify that while both SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. ”

          It stated very clear in the last sentence that REST is an architecture style!

    • **#@rs#@ ** says:

      err…so what are they then? I want to actually know…not criticizing your comment or anything.

    • SOAP is a protocol its Simple Object Access Protocol and rest is an Architecture ..REST stands for REpresentational State Transfer.

      • REST is not a protocol or an architecture, it is an architectural style

        • Sorry, submitted my post by accident.
          …with architectural properties and architectural constraints, and because this architectural style the are not officials standard for web API’s development

  4. Agree with le.terrible, SOAP is most typical example of OVERENGINEERING

  5. Good Article.

  6. well explained article, thank you!

  7. CSV is comma separated values not command separated…

  8. I loved this summary:

    “soap sucks donkeyballs – its one of the best examples of overengineering”.

    Ive done many projects with:

    1. SOAP: worked after long and painfull struggles, (when complex hierarchies wehere requested).

    2. PHP array’s as JSON strings: always works, in 1 go.

    3. CRUD interface (like REST); plain, simple, robust.

  9. After reading your article the question is still the same, should I used SOAP and REST…
    It depends you said but depends of what?

  10. Sir, I stopped reading your article when you called REST a protocol. It is an architetural style and that is a pretty huge difference. Please do not post incorrect information on the web.

    • It´s every persons right to post incorrect information everywhere they want 😉

    • I don’t understand why you are even reading the page if you already know the intricacies of both options. It is indeed important to understand the difference between a protocol and an architecture style, but I’m not sure it has any direct relevance to the information that was provided.
      It was a good summary of the basic differences between SOAP and REST.

      • @Rob I totally agree. After searching for an hour, this article has the best explanation of the differences between SOAP and REST that I have read so far. The examples were especially helpful, I am not about to get hung up on one wrong sentence in the entire FREE article

  11. Pazhaniraja.M says:

    Nice article. Thanks

  12. Good article explaining the pros and cons of traditional SOAP vs advanced REST.

  13. I followed every step in the SOAP example for VisualStudio2013, including adding the service reference. When I run the application, regardless of the address I use (and I know I am using the correct format of the address), the result is null. What am I missing?

  14. SHIVANG RANA says:

    You are wrong at one place REST is not a protocol like SOAP

  15. a simple and clear explanation of Soap and Rest. One of the best articles that i have come across in terms of deciding should i use soap or rest.

  16. Excellent Article! Very simply explained…the best SOAP/REST article I have ever read.

  17. Nice article

  18. Thanks a lot for this wonderful post.

  19. Thanks for the article,

    I have no idea why people feel that they can write mean and hateful things on the internet. Online trolls need to be kicked off the net!

  20. Scott Gordon says:

    I’m probably the only one that noticed, but I stopped reading when you called REST a protocol; it is not. That one statement completely invalidated everything you said not only in the article but throughout perpetuity.

    I feel that you owe me the time I invested in reading your free article; I will invoice you.

  21. REST is not a protocol.

  22. Dr. Judi Israel says:

    You should all be ashamed of yourselves. This is a clearly written, concise explanation (thank you!). The error has now been corrected and is understandable given the amount of content here. Your egos are such that you need to show off more than you need to understand this concept, and so you feel you can criticize. The professor in me wants to find out what bugs you all have learned and then criticize your own stupidity the same way you criticize others.

    • I’m not sure you deserve the title Dr. On of the problems we have as an industry is the confusion and pain brought about by not being precise. We don’t need to beat people up for making mistakes, but the ego is not in pointing out a mistake, it’s not being open to the idea that someone needs correction.

  23. Excellent Article! Very simply explained

  24. Another error: REST does not require HTTP. It is most commonly implemented over HTTP but it can be implemented over any transport, just like SOAP.

  25. I enjoy reading it….nice

  26. How about to develope a mobile app, which one we should use REST VS SOAP

  27. Good Article. Well explained. Thank you!

  28. Very good explanations about soap & rest. Gives clear picture

  29. Anonymous Cowherd says:

    I tried your SOAP example and I get a weird “There is an error in the XML document (1,536)” on line 123 of the auto-generated Reference.cs file. This happens when I feed it an empty address. When I use a non-empty address, I don’t get the crash. The object lesson I take from this 15 minute demo of SOAP is that auto-generated * is garbage. I REALLY DON’T LIKE CODE GENERATORS!

  30. Hi John! This was actually a clear and has an informative content. Lucky for me to visit this page.. I now see the difference between the two; The REST and THE SOAP.

  31. Some Ipv6 addresses are already in use but not to the same extent as the earlier version. Hence, this prevents your confidential data to
    be leaked out and makes way for an added security.
    There are a number of factors that can affect the VPN’s connection speed.

  32. I would suggest you to use this tool


    RestInSoap – SOAP & REST Client

    its full free and one of the best.

  33. xml “works better” than binary?
    “Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.”

  34. Kudos to John Mueller for writing this great article. It is rare to find a simple, easy to understand explanation on complex and confusing topics such as SOAP and REST.
    Thanks for doing that.

  35. Why not render both service to your customers, plenty of tools are available. Its a matter of few extra annotations (for java guys).

  36. its very useful, please continue

  37. Great information i have gain many new things about the web service thanks for sharing

  38. Good article, thanks. Being reminded that SOAP emerged from the likes of COM/CORBA made it click for me.

    One fix: CSV is ‘comma-separated values’, not ‘command’.

  39. REST is an architecture style for designing networked applications…..plz explain this …

  40. Great article!

    One point though, besides the many references throughout the article that REST is a protocol (which is just a technicality imo), I would like to state that REST does NOT require HTTP! Something you specifically mention multiple times.

  41. “These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet.”

    What a load of complete nonsense! The IP protocol is pure binary. So is the TCP protocol. Both are the foundations of the entire Internet. Are they “failing” because they are not XML-based?

    Very sad to see such “arguments” based on absolute no logic whatsoever.

  42. Espresso Beans says:

    Great article. If it was a stackoverflow post, it would get tons of upvotes for the clear and simple explanation.

  43. Great article, but many of the links are stale

  44. Richard Calladine says:

    I found this article perfect for my need to understand the difference between the two approaches. Well written and informative. Thank you for taking the time to write it.

  45. Useful.. simple way to understand SOAP & REST

  46. very Useful post

  47. I get lost at two points. When people use the words “always” and “vs.”. REST and SOAP are both useful, still useful tools. Like many other tools there are cases for both. For example I do a lot of Habitat for Humanity builds. I have a lot of hammers. I have framing, finish, demolition, mason’s, and a maul. All hammers but each have their use different uses. REST and SOAP are the same.

  48. Great article in general.
    I found that REST can be used over ANY protocol, yes, you could use REST with SMTP, or FTP, or even TELNET… but, HTTP/s is particularly well suited for this technique!
    For everything else, I quite agree with you, and one should choose the tool that best suits one’s needs!

  49. Great work ……. as there are some mistakes…. but good information on single page….good one

  50. Wonderful Article!. Thanks for sharing your knowledge.

  51. Well Explained!!! Showed the difference and made me understand the actual information!!
    If you can share more on WCF is appreciated

  52. Nice one!

  53. Binh Thanh Nguyen says:

    Very informative. Nice post.

  54. It was really nice article. Literally article learned me general concept of Rest and SOAP web services thank you really was useful.

  55. Only problem is: Example did not work.

    There was an error downloading ‘http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl/$metadata’.
    The remote name could not be resolved: ‘rpc.geocoder.us’
    Metadata contains a reference that cannot be resolved: ‘http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl’.
    There was no endpoint listening at http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
    The remote name could not be resolved: ‘rpc.geocoder.us’
    If the service is defined in the current solution, try building the solution and adding the service reference again.

  56. The links of a ws are broken ! Nice post.

  57. Nice article, kudos!

  58. Superb and Simple! Thanks!

  59. Niroshan Vijayarasa says:

    really well written ! Thanks !

  60. Very Cool

  61. This is absolutely useful and informative, do you mind if i cite your works for my final paper for my network class?

  62. Doesn't matter says:

    Someone tries to sell SOAP by any mean. Plenty of misconceptions and many lies in favour of SOAP in the article, like “REST requires HTTP”, bollocks.

  63. Very well written post,
    Thanks for sharing such grateful information which is very helpful to many people who want to learn Java Language. Web service is a way of communication between different devices over the internet. SOAP is an XML based protocol. REST is an architecture style, not a protocol. REST allows different data formats like HTML, XML, JSON whereas SOAP allows only XML data format.

  64. Binh Thanh Nguyen says:

    Thanks, nice post

  65. Anupkumar Mahamalla says:

    Perfect Article for SOAP vs REST.
    Very simply explained

  66. Abderrahmane K says:

    This is great article. I have been struggling to find the difference between SOAP and REST. Your article says it all.
    Thank you and good luck.

  67. Well covered difference in SOAP & REST

  68. Great information about this.i really enjoy to red about this.

  69. nice explanation..
    thank you

Speak Your Mind