Web-Services Comparisons with SOAP and REST

Web Services Developing with SOAP and REST

There are currently two schools of thought in developing Web Services – one being the standards-based traditional approach [SOAP] and the other, simpler school of thought [REST].

What is SOAP?

Defined as Simple Object Access Protocol, it is a specification for exchanging structured information using Extensible Markup Language (XML) and usually HTTP protocol for transmission. SOAP also uses Web Services Description Language (WSDL) documents that provide a model for describing web services. Basically, it defines what the SOAP request (client-side) and response (server-side) should look like.

What is REST?

The acronym REST stands for Representational State Transfer, meaning each unique URL represents some object. The architecture was developed by Roy Fielding, one of the authors of the Hypertext Transfer Protocol (HTTP). A REST Web Service uses HTTP and supports the HTTP GET, POST, PUT or DELETE methods.

How popular is REST?

All of the major web services on the Internet now use REST: Twitter, Yahoo’s web services use REST, others include Flicker, del.icio.us, pub.sub, blog, lines, techno and several others. Both eBay and Amazon have web services for both REST and SOAP.

Basic differences:

REST		SOAP
Pros	Cons	Pros	Cons
Lightweight	Point-to-point communication	Easy to consume	More difficult to setup
Human Readable	Lack of standards	Standards (WSDL,XSD, policy etc)	More verbose
Easier to build	Tied to HTTP	Distributed computing	Harder to develop

Detail level comparisons for SOAP and REST:

REST	SOAP
Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries	Designed to handle distributed computing environments
Minimal tooling/middleware is necessary. Only HTTP support is required	Requires significant tooling/middleware support
URL typically references the resource being accessed/deleted/updated	The content of the message typically decides the operation
Not reliable – HTTP DELETE can return OK status even if a resource is not deleted	Reliable
URL typically references the resource being accessed/deleted/updated	The content of the message typically decides the operation
Not reliable – HTTP DELETE can return OK status even if a resource is not deleted	Reliable
Formal description standards not in widespread use. WSDL 1.2, WADL are candidates.	Well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy
Better suited for point-to-point or where the intermediary does not play a significant role	Well suited for intermediated services
No constraints on the payload	Payload must comply with the SOAP schema
Only the most well established standards apply e.g. HTTP, SSL. No established standards for other aspects.  DELETE and PUT methods often disabled by firewalls, leads to security complexity.	A large number of supporting standards for security, reliability, transactions.
Built-in error handling (faults)	No error handling
Tied to the HTTP transport model	Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP
Less verbose	More verbose