A lot of web services are implemented using a REST style architecture these days instead of SOAP architecture. Preference of a REST or SOAP over another has been a long debate in industry. Lets discuss what these two services mean and the differences between both of them:

REST Web Service

• REST stands for Representational State Transfer, this means that each unique URL is a representation of some object.
• You can get the contents of that object using an HTTP parameter GET
• You can modify/delete object using HTTP parameters like POST, PUT, or DELETE (most services use POST in practice)
• Web works on REST style architecture. A shared resource repository and consumers access the resources.

SOAP Web Service

• SOAP stands for Simple Object Access Protocol
• SOAP is a simple XML-based protocol used for communication between applications and for accessing a Web Service
• SOAP is a format for sending messages
• SOAP uses XML padding around the message objects. Data sent/received over HTTP as XML.
• SOAP uses interfaces and named operations to expose business logic.
• SOAP/ RPC over HTTP encourages each application designer to define new, application specific operations that supplant HTTP operations.
• SOAP e.g. getUsers() getNewUsersSince(date SinceDate) saveOrder(string CustID, string orderID)
• SOAP has Stateful operations and additional standards to ensure reliability and security

REST vs. SOAP

• SOAP is a XML based messaging protocol and REST is not a protocol but an architectural style.
• REST uses HTTP operations (request methods) and other existing features of the HTTP protocol while SOAP/ RPC over HTTP encourages application designer to define new, application specific operations that supplant HTTP operations.
• SOAP has a standard specification but there is none for REST.
• REST does not enforces message format as XML or JSON or etc. But SOAP is XML based message protocol.
• REST based implementation is simple compared to SOAP and consumer understanding.
• SOAP has a set of standard specifications. WS-Security is the specification for security in the implementation. Like this we have separate specifications for messaging, transactions, etc. Unlike SOAP, REST does not has dedicated concepts for each of these. REST predominantly relies on HTTPS.
• REST has 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, REST is it.
• SOAP supports Stateful operations if the application needs contextual information and conversational state management then SOAP has the additional specification in the WS* structure to support those
• SOAP has WS-Security specification. In REST HTTPS is used to secure messages over network. In SOAP using WS-Security spec, we can use message encryption, signature and all these over HTTPS.
• For a guaranteed level of reliability and security SOAP offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.

REST advantages:

• Limited bandwidth and resources;
• Return structure is in any format (developer defined)
• Any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs
• REST can also use XMLHttpRequest object for AJAX support.
• SOAP has additional vocabulary that disregards many of HTTP’s existing capabilities like authentication, caching etc.

More about SOAP

A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this.

SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

A SOAP message is an ordinary XML document containing the following elements:

• An Envelope element that identifies the XML document as a SOAP message
• A Header element that contains header information
• A Body element that contains call and response information
• A Fault element containing errors and status information

Syntax Rules for a SOAP Message

• MUST be encoded using XML
• MUST use the SOAP Envelope namespace
• MUST use the SOAP Encoding namespace
• MUST NOT contain a DTD reference
• MUST NOT contain XML Processing Instructions

REST Example

The following URL sends a REST request to Twitter’s search service: http://search.twitter.com/search.atom?q=windows&count=5

This specific search request searches for the string "elkstein", as set by the q parameter and limits the response to at most 5 results, using the count parameter. There are, of course, many additional parameters.

The returned response is in XML. A slightly different URL (this one) can be used to obtain results in JSON format.

http://search.twitter.com/search.json?q=windows&count=5

E.g. GET http://del.icio.us/api/peej/bookmarks/?start=1&end=2

And as the smart guys over Stack Overflow shared a comic to differentiate between REST and SOAP,

People in industry have adapted both REST and SOAP and they are being used in almost every top tech company like Google, Yahoo, Amazon. Whatever you use make sure you use these web services around your task not your task around web services.