REST VS SOAP

REST is a software architecture style consisting of guidelines and best practices for creating a 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.”

 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.”
“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 comprehensive 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 the 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 the browser clients.
REST has better performance and it is scalable: REST can be cached, SOAP can’t be.
Conclusion:
Even though REST seems to be in favour now I think there are some cases when SOAP makes sense when you choose it: if I was writing a smart phone application to interface with a service that provides confidential data I would definitely need to use SOAP. All features (WS-Security, WS-AtomicTransaction, WS-ReliableMessaging) are required for this kind of service


Comments

Post a Comment

Hi,

If any one want to give the stagnation and change its most welcome.

Thanks!!
Rajesh Singh.

Popular posts from this blog

Many to Many Relationship in Dynamics CRM 2011.

Image
I get asked about many-to-many (a.k.a. N:N) relationships more than just about any other single topic, so here’s a summary of how they work in Dynamics CRM 2011. I’ll review both “native” and “manual” N:N’s, using a simple Association to Contact relationship to illustrate. This is a classic many-to-many: each association should be able to have multiple contacts associated with it, and each contact should in turn be able to be associated with many associations. Native N:N Relationships With native N:N relationships, you open up an entity for customization, click the N:N relationships link, and click the  New Many to Many Relationship  button and select the entity to create the relationship to. For the Association to Contact N:N relationship, I’ll start from the Association entity: In the previous figure, notice that Do no Display is selected in the Display Option for each side. I only show that to illustrate a point: what this will do is prevent the relationship from be...
Read more

Difference between CRM Discovery Service and CRM Metadata service?

CRM service - when we need ORG related information like ORG name, Properties, CRM service path for this ORG -- then we use CRM discovery service. This is only to get the ORG related information Metadata service - we use this when we need to interact with the CRM records – create, update or delete anything-- it is very specific to the CRM records. When we need to interact with the CRM entity and attribute - like create an entity (not record) or attribute -- add a value to pick list-- retrieve the pick list value retrieve the entity properties-- attribute property and all we need Meta data service.
Read more

Create a Custom Workflow Activity...

Image
Required Software and Assemblies To develop Windows Workflow Foundation 4 custom activities, you must develop them on Microsoft .NET Framework 4. If you plan to register your custom workflow activities with Microsoft Dynamics CRM Online, you must build them using the Microsoft .NET Framework 4  PU3  (platform update 3) or a later version, such as .NET 4.5. The following assemblies must be added as references in your project. They can be found in the  SDK\Bin  folder in Microsoft Dynamics CRM SDK. Microsoft.Xrm.Sdk.dll Microsoft.Xrm.Sdk.Workflow.dll Use the CodeActivity Workflow Base Class To create a custom workflow activity, create a class that inherits from the  CodeActivity  workflow base class. This class is available in the  System.Activities namespace. Activities that inherit from the  CodeActivity  class can override the  Execute  method to produce custom functionality. To create a custom activity...
Read more