Interview Question: Compare two web services type SOAP and RESTful (SOAP Vs RESTful)

I have been giving a series of technical interviews lately. One of the interview questions was to compare the two Web Services types; namely SOAP based Web Services and RESTful Web Services. Although I was able to provide a satisfactory answer, I felt more was required. I did some research and the following information was have gathered, aggregated and presented in a tabular format for my readers to act as a ready reckoner. In case you find more do let me know.

Criteria SOAP RESTful Comments
Specification JAX-WS JAX-RS Added on 28th Dec 2011.
Orientation Wraps business logic Accesses resources/data
Developer View Object oriented Resource Oriented
Language Independence Yes Yes
Platform Independence Yes Yes
Simplicity No Yes
Standards Based Yes No SOAP web services are based on SOAP and WS-* specifications
Security SSL, WS-Security SSL WS-Security provides end-to-end security covering message integrity and authentication
Transactions WS-AtomicTransaction No
Reliability WS-ReliableMessaging Application specific
Performance Good Better Caching and lower message payload makes RESTful web services performance efficient and scalable
Caching No GET operations can be cached
Transport protocol support HTTP, SMTP, JMS HTTP Multiple transport protocol support makes SOAP Web Services flexible
Message Size Heavy, has SOAP and WS-* specific markup Lightweight, no extra xml markup
Message Communication protocol XML XML, JSON, other valid MIME type This flexibility of REST makes its extremely useful in providing consumer need specific message payloads
Message Encoding Yes No SOAP Web Services support text and binary encoding, RESTful encoding is limited to text
Service Description WSDL No formal contract definition In REST, no formal way to describe a service interface means more dependence on written documentation
Human intelligible Payload No Yes
Developer Tooling Yes Minimal or none Complexity of SOAP Web Services dictates the need for using frameworks to facilitate rapid application development. REST on the other hand due to its simplicity can be developed without any framework
Attachment Support via SAAJ specification RESTful WS implementation specific support Added on 28th Dec 2011. Thanks Ron Grimes

Now we come to most important stage of deciding which type to select. There is no one answer for selecting either SOAP based or RESTful Web Services. Neither is the right choice for every situation. The choice is dependant upon specific needs and which solution addresses them best. An architect should ask the following questions and the responses should assist him/her in making an informed decision:

  • Does the service expose data or business logic? (REST can be a good choice for exposing data, SOAP/WS-* might be a better choice for logic)
  • Does the service need the capabilities of WS-*, or is a simpler RESTful approach sufficient?
  • What’s best for the developers who will build clients for the service?

Areas where RESTful WebServices are a great choice:

  • Limited bandwidth and resources: Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.
  • Totally stateless operations: If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is suitable.
  • Caching situations: If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.

Areas where SOAP based WebServices is a great solution:

  • Asynchronous processing and invocation: If application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging etc.
  • Formal contracts: If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.
  • Stateful operations: If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

I have used a lot of information from resources generously shared by fellow bloggers. It would inconsiderate in case I do not mention them. The resources are:

  1. REST and SOAP: When to use each (or both)?
  2. SOAP vs REST: Complements or Competitors
  3. Introduction to Web APIs: REST vs SOAP

That’s it from my end. Do let me know in case you observe any oversights or can suggest improvements.


27 thoughts on “Interview Question: Compare two web services type SOAP and RESTful (SOAP Vs RESTful)

  1. Well, WADL is the standard format for describing RESTful webservice interfaces… its still a maturing standard though!

    1. I am aware of WADL and its use as a descriptive language for RESTful WS, I am not sure about its acceptance.

  2. Nice post but the structure and content of your article is clearly copied and pasted from Dave Chappell’s reference article 2.SOAP vs REST: Complements or Competitors. Lock, stock and barrel. This is not really research.

    1. Hi Fowler,

      My intention was to consolidate all the information available on Web Services comparison as a single post. Nor did I intend to hide the resources used, I have clearly mentioned the references used near the end of the post. As regards ‘research’, fair enough I am removing that reference.

  3. Using Visual Studio I have found SOAP to be much easier to implement then REST. For .Net clients, ie MonoDroid, MonoTouch, Wp7, Silverlight, etc. SOAP is much more reliable and easier to consume. However, when working in more limited platforms, ie Java, iOS Native, Script; that have no built-in SOAP, then REST would seem to be easier to consume. However the lack of self-descriptive contracts as in VS SOAP, makes coding the service and client more error prone and tedious. It is unfortunate that MS did not implement REST in a similar manner as they did SOAP (using the WebMethod attribute)

    1. Hi J Longo,

      Thanks for sharing your thoughts. I am a more Java guy, hence it is refreshing to hear thoughts from the .NET world. Just to clarify, Java EE 6 the enterprise platform does provide built-in support for SOAP as well as RESTful web services(WS). Also there are number of open source projects that provide WS support. I have personally implemented SOAP using the Axis project and tried implementing RESTful WS using RESTEasy. Implementation is pretty easy. I believe using annotations in RESTEasy is similar to the webMethod implementation of .NET. So to me ease of implementation is the same for both WSs.
      As regards, self describing nature I agree that can be a bit of a bother with RESTful WS, however the flexibility of using any data communication format like JSON or any other MIME type is a boon. I believe as we move on to a world where data sharing will become a norm, having end receiver compatible format will become a necessity.

      There has been some thought around using WADL as the RESTful WS description format; however the effort is lacking in momentum.

      I believe both WSs will complement each other and over time based on applicability/strength be the ‘WS of choice’. Given the popularity of RESTful WS, I am sure MS will start providing some support. It is a momentum it can choose to ignore at its own peril.

  4. A very nice overview, although I would like to add some remarks.

    I would disagree with some of your entries in the table. For example the item “Standards based”. HTTP is of course a standard and the fixed semantics of the HTTP interface is one of the main advantages of REST over SOAP or RPC-style services.

    Also, I would say REST is transport-agnostic (although of course nothing besides TCP seems to be used at all). One difference between RESTful web services and SOAP is that RESTful web services actually use HTTP for its intended purpose – as an application level protocol, not just a transport protocol.

    1. Hi Schlebu,

      When I am referring to ‘standards based’, I am talking about SOAP. SOAP protocol is a W3C standard. The payload in case of RESTful web service is flexible; XML or JSON or just plain text, which is not a standard.

      I agree that in principle REST is transport protocol agnostic. But the present day REST based Web Services or RESTful Web Services use only HTTP. Therefore as a parameter of comparison between SOAP based and RESTful based Web Services, RESTful WS use only HTTP.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s