SOAP:
1. Developer View: Object oriented
2. Standards Based: Yes .
SOAP web services are based on SOAP and WS-* specifications
For acquiring security tokens,it uses WS-Trust.
For conveying security tokens, it uses WS-Security
For defining policy, it uses WS-Policy
For suppoting distributed ACID transactions, it uses WS-AtomicTransaction and WS-Coordination
For acquiring interface definitions, it uses WS-MetadataExchange
For providing end-to-end reliability, it uses WS-ReliableMessaging
For establishing security context, it uses WS-SecureConversation
3. Security: SSL, WS-Security .
WS-Security provides end-to-end security covering message integrity and authentication
4. Transactions : WS-AtomicTransaction
5. Reliability : WS-ReliableMessaging
6. Performance: Good
7. Caching : No
8. Message Size : Heavy, has SOAP and WS-* specific markup
9. Message Communication protocol : XML
10. Message Encoding :Yes
SOAP Web Services support text and binary encoding
11. Service Description :WSDL
12. Human intelligible Payload :No
13. Developer Tooling :Yes
Complexity of SOAP Web Services dictates the need for using frameworks to facilitate rapid application development.
14. Orientation :Wraps business logic
15. Abbreviation: SOAP stands for Simple Object Access Protocol
16. Who is using SOAP? 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.
17. Simplicity: No
18. Transport protocol support: HTTP, SMTP, JMS
Multiple transport protocol support makes SOAP Web Services flexible
REST:
1. Developer View: Resource Oriented
2. Standards Based: No
3. Security: SSL
4. Transactions : No
5. Reliability :Application specific
6. Performance: Better
Caching and lower message payload makes RESTful web services performance efficient and scalable
7. Caching : GET operations can be cached
8. Message Size : Lightweight, no extra xml markup
9. Message Communication protocol : XML, JSON, other valid MIME type .
This flexibility of REST makes its extremely useful in providing consumer need specific message payloads
10. Message Encoding : No
RESTful encoding is limited to text
11. Service Description : No formal contract definition
In REST, no formal way to describe a service interface means more dependence on written documentation
12. Human intelligible Payload : Yes
13. Developer Tooling : Minimal or none
REST on the other hand due to its simplicity can be developed without any framework
14. Orientation : Accesses resources/data
15. Abbreviation: REST stands for Representational State Transfer
16. Who is using REST? 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.
17. Simplicity: Yes
18. Transport protocol support: 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.