After the presentation by the CIS Integratem team on REST last week I began to wonder as to what the major differences between REST based and SOAP based webservices are and why in some cases REST is preferred and in others for SOAP. This is what I found:
At a fundamental level the difference between REST based WS and SOAP based WS depends on whether the application is Resource oriented or Activity Oriented.
REST based WS can be classified as Resource Oriented. Resources are identified and located by a Universal Resource Identifier (URI), and the operations that might be performed against those resources are defined by the HTTP specification. In RESTful web services, the emphasis is on simple point-to-point communication over HTTP using plain old XML (POX).
REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) and the nouns, which are the resources available on the network (referenced in the URI). The verbs have the following operational equivalents:
HTTP CRUD Equivalent
===== =========================
GET read
POST create, update, delete
PUT create, update
DELETE delete
On the other side of the coin are Activity-Oriented Services. SOAP based WS are typically Activity Oriented.These types of applications focus on actions that you might perform rather than on the resources upon which they act. Unlike resource-oriented services, where the operations that might be performed remain relatively constant regardless of the type of resource, operations in activity-oriented services depend entirely on the type of activities being performed.
In resource-oriented services, a common set of operations play a supportive role, allowing clients to access and manipulate resources. However, the resource is the center of attention, as shown in Figure 1 below.
Figure 1. Comparing resource-oriented services (REST) to activity-oriented (SOAP) services
In activity-oriented services, the operations are the center of attention, with a single operation for each activity the client might request to be performed.
The Pros and Cons of the SOAP and REST based WS can be summed as follows:
SOAP
Pros:
• Language, platform, and transport agnostic
• Designed to handle distributed computing environments
• Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
• Built-in error handling (faults)
• Extensibility
Cons:
• Conceptually more difficult, more "heavy-weight" than REST
• More verbose
• Harder to develop, requires tools
REST
Pros:
• Language and platform agnostic
• Much simpler to develop than SOAP
• Small learning curve, less reliance on tools
• Concise, no need for additional messaging layer
• Closer in design and philosophy to the Web
Cons:
• Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
• Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
• Tied to the HTTP transport model
The REST architecture might appear less complex as compared to the SOAP WS arch but it should also be kept in mind that it offers less functionality in key areas such as reliable messaging .
Hence, while deciding on the type of WS to be used the Pros and Cons of each should be considered and also the kind of functionality which is desired should be taken into account.
References:
http://www.ibm.com/developerworks/webservices/library/ws-restvsoap/?S_TACT=105AGY82&S_CMP=GENSITEhttp://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
