Definitions
REST
„REST is a software architecture style consisting of guidelines and best practices for creating scalable web services. REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.REST has gained widespread acceptance across the Web as a simpler alternative to SOAP and WSDL-based Web services. RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.”
(from Wikipedia)
SOAP
“SOAP, originally an acronym for Simple Object Access protocol, is a protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on other application layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.”
(from Wikipedia)
“Should I REST or Should I SOAP?”
I have spent hours fretting over the choice between SOAP and REST finding the answer. Some Web services support one and some support the other. Microsoft Dynamics CRM supports both. Our decision depends on which web service best meets your NEEDS, rather than which PROTOCOL to USE!
SOAP is a heavyweight player: it provides the following advantages when we compare to REST:
Security:
SOAP supports SSL – just like REST – but also support WS-Security (Web Services Security is an extension to SOAP to apply security to Web Services. WS-Security supports identity through intermediaries, not just point to point. It implements data integrity and data privacy.
Transactions:
Need ACID (Atomicity, Consistency, Isolation, Durability) Transactions over a service? You need SOAP. However REST supports transactions, it is not as comprenesive and is not ACID compliant! REST has its own weakness: it is limited by HTTP itself: HTTP is not able to provide two -phase commit across distributed transactional resources, but SOAP can.
Reliability:
SOAP supports WS-ReliableMessaging which is a protocol that allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures.
Let me show you some reasons why REST is almost the “right” answer:
REST uses standard HTTP: it means it is much simpler in some cases:
Creating clients and APIs is easier than SOAP.
Performance:
REST permits many different data formats: SOAP only permits XML. REST supports JSON which is a better fit for data because it parses much FASTER!. REST allows BETTER support for most of browser client.
REST has better performance and it is scalable: REST can be cached, SOAP can’t be.
Conclusion:
Even though REST seems to be in favor now I think there are some cases when SOAP makes sense when you choose it: if I was writing an smart phone application to interface with a service which provides confidental data I would definitely need to use SOAP. All features (WS-Security, WS-AtomicTransaction, WS-ReliableMessaging) are required for this kind of service.
Reference -
No comments:
Post a Comment