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.
|Specification||JAX-WS||JAX-RS||Added on 28th Dec 2011.|
|Orientation||Wraps business logic||Accesses resources/data|
|Developer View||Object oriented||Resource Oriented|
|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|
|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:
- REST and SOAP: When to use each (or both)?
- SOAP vs REST: Complements or Competitors
- 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.