REST (Representational State Transfer) and SOAP (Simple Object Access Protocol) represent two very different styles to implement a Web Service. There is a whole lot of analysis done on what to use.. Here is my understanding.

REST represents an architecture style and is designed to reduce complexity by dividing the system into resources. The resources and operations supported by a resource are represented and exposed through a set of URIs (HTTP addresses) logically on the HTTP protocol.

SOAP is a protocol based on messages that is used to implement the messages layer of a Web Service. The message consists of an “envelope” with a header and a body. The header can be used to provide information external to the operation to be performed by the service (e.g., security aspects, transactional aspects or message routing, included in the header).

The main difference between these two approaches is the how the service state is maintained.

With SOAP, changing through different states is made by interacting with a single service endpoint which encapsulates many operations and message types.

With REST, we have a limited number of operations and these operations are applied to resources represented and addressed by URIs (HTTP addresses). The messages are composed by current resources states or the required resources state.

REST works very well with Web applications where HTTP can be used as protocol for data types other than XML (like JSON). The service consumers interact with the resources through URIs in the same way people can navigate and interact with Web pages through URLs (web addresses).

The following diagram shows what scenarios REST or SOAP fit better

  Advantages Disadvantages
SOAP Strongly typed proxies – WSDL SOAP messages are not „cacheable‟ by CDNs. This is a very serious handicap for high scalable applications in the Internet
SOAP Supports different communication protocols. (HTTP/TCP/MSMQ/Named
SOAP messages are not JavaScript friendly (For AJAX, JQuery, etc. REST is the best choice).
REST Services act as Resources, such as images or HTML documents Working with strongly typed objects is harder, although this depends on technological implementations and it is improving in the latest versions of most platforms
  Data can be maintained strictly or decoupled (not as strict as SOAP) Only works over HTTP, and REST calls are restricted to HTTP verbs (GET, POST, PUT, DELETE, etc.). But, it this really a disadvantage for the Internet and interoperable solutions? 
  REST resources can be easily used from the JavaScript code (AJAX, JQuery, etc.)  
  Messages are light, so the performance and scalability offered are high. This is important for many Internet applications  
  REST can use XML or JSON as data format  
  REST messages are „cacheable‟ by CDNs thanks to the HTTP GET verb being used like any HTTP-HTML web-site. This is a great advantage for high scalable applications in the Internet  


Even though both approaches (REST and SOAP) may be used for similar types of services, the approach based on REST is normally more suitable for Distributed Services that are publicly accessible (Internet) and require high scalability or in cases where a Service can be accessed by unknown consumers. SOAP, on the contrary, is still a good approach for implementing procedural implementation ranges, such as an interface between the different layers of Application architecture or, ultimately, private Business Applications.

SOAP does not limit to HTTP. The standard specification WS-*, which can be used on SOAP, provides a standard and therefore interoperable path to work with advanced aspects such as SECURITY, TRANSACTIONS, ADDRESSING AND RELIABLE-MESSAGING. But, frankly, these advanced WS-* specifications have not been broadly adopted and used by most applications in the Internet and even when they are standard specifications, its degree of compatibility between different technical platforms is not really high, mostly due to its complexity.

REST also offers a great level of interoperability (due to the simplicity of its protocol); however, for advanced aspects, such as those previously mentioned, it would be necessary to implement their own mechanisms, which would be non-standard.

In short, both protocols allow us to interchange data by using verbs.

The difference lies in the fact that, with REST, this set of verbs is restricted to coincidence with HTTP verbs (GET, PUT, etc.) and in the case of SOAP, the set of verbs is open and defined in the Service endpoint.

– SOAP is a protocol that provides a messaging framework that a layer abstraction can be built on, and it is mostly used as an RPC calls system (synchronous or asynchronous) where data is transferred as XML messages.

– SOAP manages aspects, such as security and addressing, through its internal implementation of SOAP protocol.

– REST is a technique that uses other protocols, such as JSON (JavaScript ObjectNotation) and Atom as a publication protocol, and simple and light formats of the POX type (Plain Old XML).

– REST enables the use of standard HTTP calls such as GET and PUT to make queries and modify the state of the system. REST is stateless by nature, which means each individual request sent from the client to the server must contain all the necessary information in order to understand the request, since the server will not store data about the state of the session.

SOAP is a protocol based on messages that is used to implement the messages layer of a Web Service. The message consists of an “envelope” with a header and a body. The header can be used to provide information external to the operation to be performed by the service (e.g., security aspects, transactional aspects or message routing, included in the header).

Source : MSDN



REST – Differences between PUT & POST.


PUT implies putting a resource – completely replacing whatever is available at the given URL with a different thing. By definition, a PUT is idempotent. Call it as many times as you like, and the result is the same. x=5 is idempotent.

One can PUT a resource whether it previously exists, or not (eg, to Create, or to Update)!

POST updates a resource, adds a subsidiary resource, or causes a change.

A POST is not idempotent, in the way that x++ is not idempotent.

Open Sourcery

Web service designers have tried for some time now to correlate CRUD (Create, Retrieve, Update and Delete) semantics with the Representational State Transfer (REST) verbs defined by the HTTP specification–GET, PUT, POST, DELETE, HEAD, etc.

So often, developers will try to correlate these two concepts–CRUD and REST–using a one-to-one mapping of verbs from the two spaces, like this:

  • Create = PUT
  • Retrieve = GET
  • Update = POST
  • Delete = DELETE

“How to Create a REST Protocol” is an example of a very well-written article about REST, but which makes this faulty assumption. (In fairness to the author, he may well have merely “simplified REST for the masses”, as his article doesn’t specifically state that this mapping is the ONLY valid mapping. And indeed, he makes the statement that the reader should not assume the mapping indicates a direct mapping to SQL operations.)

In the article, “I don’t get PUT versus…

View original post 731 more words