SOAP versus RESTful Web service -- comparison

SOAP versus RESTful Web service -- comparison

Recently I attended an interview with a large investment bank, and I was quizzed on SOAP versus RESTful web service. The interview questions were targeted at ascertaining my understanding of the differences, pros and cons of each, and when to use what.

Web services are very popular and widely used to integrate similar (i.e. Java applications) and disparate systems (i.e. legacy applications and applications written in .Net etc). It is imperative to understand the differences, pros, and cons between each approach.

Key Area	SOAP based Web service	RESTful Web service
Specification/Platform Fundamentals (SF/PF)	Transport is platform & protocol neutral. Supports multiple protocols like HTTP(S), Messaging, TCP, UDP, SMTP, etc. Permits only XML data format, hence language neutral. You define operations, which tunnels through thePOST or GET. The focus is on accessing the named operations and exposing the application logic as a service. Defines the contract via WSDL.	Transport is protocol specific. Supports only HTTP or HTTPS protocols. Permits multiple data formats like XML, JSON data, text, HTML, atom, RSS, etc. Any browser can be used because the REST approach uses the standard GET, PUT, POST, andDELETE web operations. The focus is on accessing the named resources and exposing the data as a service. Traditionally, the big drawback of REST was the lack of contract for the web service. This has changed with WSDL 2.0 defining non SOAP bindings and the emergence of WADL. Simpler to implement. REST has Ajax support. It can use the XMLHttpRequest object. Good for stateless CRUD (Create, Read, Update, and Delete) operations.
Performance Consideration (PC)	SOAP based reads cannot be cached. The application that uses SOAP needs to provide cacheing.	REST based reads can be cached. Performs and scales better.
Security (SE)	Supports both SSL security and WS-security, which adds some enterprise security features. Supports identity through intermediaries, not just point to point SSL. WS-Security maintains its encryption right up to the point where the request is being processed. WS-Security allows you to secure parts (e.g. only credit card details) of the message that needs to be secured. Given that encryption/decryption is not a cheap operation, this can be a performance boost for larger messages. It is also possible with WS-Security to secure different parts of the message using different keys or encryption algorithms. This allows separate parts of the message to be read by different people without exposing other, unneeded information. SSL security can only be used with HTTP. WS-Security can be used with other protocols like UDP, SMTP, etc.	Supports only point-to-point SSL security. The basic mechanism behind SSL is that the client encrypts all of the requests based on a key retrieved from a third party. When the request is received at the destination, it is decrypted and presented to the service. This means the request is only encrypted while it is traveling between the client and the server. Once it hits the server (or a proxy which has a valid certificate), it is decrypted from that moment on. The SSL encrypts the whole message, whether all of it is sensitive or not.
Transaction Management (TM)	Has comprehensive support for both ACID based transaction management for short-lived transactions and compensation based transaction management for long-running transactions. It also supports two-phase commit across distributed resources.	REST supports transactions, but it is neither ACID compliant nor can provide two phase commit across distributed transactional resources as it is limited by its HTTP protocol.
Quality of Service (QoS)	SOAP has success or retry logic built in and provides end-to-end reliability even through SOAP intermediaries.	REST does not have a standard messaging system, and expects clients invoking the service to deal with communication failures by retrying.
Best Practice (BP)	In general, a REST based web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security, transactional reliability and stricter contract.

SOA (Service Oriented Architecture) versus WOA (Web Oriented Architecture)

(Source: )


SOA and WOA differ in terms of the layers of abstraction. SOA is a system-level architectural style that tries to expose business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumers. You can start out with a WOA and then grow into SOA.