Difference between SOAP and REST

Difference between SOAP & REST

Many times this question has been asked by several people. Even people know how to use them, but rarely they might thought why,what and when this 2 has to be used. Today i will be enlighten on these 2 terms.

First we will learn about SOAP and REST one by one. After that we will examine the differences.

SOAP

What is SOAP

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

History

SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time.[1] The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.

Transport Protocols

There are various transport methods availeable for SOAP. Like HTTP, SMTP, HTTPS, JMS, Message Queue

Message Formatting

XML Information Set was chosen as the standard message format because of its widespread use by major companies and open source development efforts. Typically, XML Information Set is serialized as XML.

REST

What is REST

REST is short name of REpresentational State Transfer and is a style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a predominant web API design model.

History

The term REpresentational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.[1][2] Fielding is one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.[3][4]

How Rest Works

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information). For example, a resource that represents a circle (as a logical object) may accept and return a representation that specifies a center point and radius, formatted in SVG, but may also accept and return a representation that specifies any three distinct points along the curve (since this also uniquely identifies a circle) as a comma-separated list.
Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without "seeing past" its own request (referred to as "layering", another constraint of REST and a common principle in many other parts of information and networking architecture). Thus, an application can interact with a resource by knowing two things: the identifier of the resource and the action required—it does not need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and the server actually holding the information. The application does, however, need to understand the format of the information (representation) returned, which is typically an HTML, XML, or JSON document of some kind, although it may be an image, plain text, or any other content.
It uses HTTP protocol and its verb to actions on resources.

Basically resource is on the server, and representation is a formatted message how the uri to be interacted like it can be in JSON, HTML, XML.

The HTTP verbs are used to act upon on the URI.

GET - Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.
PUT- Replace the addressed member of the collection, or if it doesn't exist, create it.
POST-Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.
DELETE-Delete the addressed member of the collection.

Message Formatting

Message Formatting can be in JSON, XML, HTML.  Also response can be in any media type like image.


So far we undersand the basic idea about SOAP and REST. But still we need to see their differences. Below is the list of differences.

S.No.	Point of View	SOAP	REST
1	Abbreviation	SOAP stands for Simple Object Access Protocol	REST stands for Representational State Transfer
2	What	Is a Protocol	Is a style of Software Architecture
3	Developer View	Object oriented	Resource Oriented
4	Standards Based	Yes	No
5	Security	SSL, WS-Security	SSL
6	Transactions	WS-AtomicTransaction	No
7	Reliability	WS-ReliableMessaging	Application specific
8	Performance	Good	Better
9	Caching	No	GET operations can be cached
10	Message Size	Heavy, has SOAP and WS-* specific markup	Lightweight, no extra xml markup
11	Message Communication protocol	XML	XML, JSON, other valid MIME type
12	Message Encoding	Yes SOAP Web Services support text and binary encoding	No
13	Service Description	WSDL	No formal contract definition
14	Human intelligible Payload	No	Yes
15	Developer Tooling	Yes	Minimal or none
16	Orientation	Wraps business logic	Accesses resources/data
17	Who is using ?	Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well.	All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP
18	Simplicity	No	Yes
19	Transport protocol support	HTTP, SMTP, JMS	HTTP

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.

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.



I  suppose this would help you to see the differences between SOAP and REST. I would like to thank the following references that helped me a lot to write this blog.

http://www.dotnetobject.com
http://en.wikipedia.org