This is a great question because it relates to a recent re-alignment of what used to be called “ADO.NET Data Services” (code-named Astoria) under the umbrella of Windows Communication Foundation (WCF), as well as the renaming of .NET RIA Services to WCF RIA Services.  I’m going to steal an image from the .NET Endpoint blog, because it shows how each programming model rests on top of the infrastructure provided by WCF.

The two bottom layers should be quite familiar to anyone who uses WCF, but the diagram could mistakenly lead you to the conclusion that the programming model section is independent of the underlying Service Model and Channel layers.  The truth is that RIA Services rests on Data Services, which is turn sits on top of Web HTTP Services (aka REST), which is tightly coupled to HTTP as a transport and XML, Atom or Json as a format.  Only SOAP Services (leaving Workflow Services aside for the moment) can be used with any format and transport protocol.

Practically speaking, what this means is that there is a fork in the road when it comes to deciding how to implement an n-tier application architecture.  WCF SOAP Services (that is, traditional WCF) offers the most flexibility when it comes to selecting an underlying transport.  For example, I may want to use a NetMsmqBinding with clients and services that are occasionally connected.  The other way to go is to select a REST-based programming model, which leverages the universality of the HTTP protocol and uses a URI addressing scheme.  If flexibility concerning the transport layer matters to you, then traditional SOAP-based WCF services are the way to go.

Another differentiating factor is that WCF SOAP Services tend to be operation-based, while REST services are said to be resource-based.  That means clients are effectively going to call methods on a SOAP service, while client of a REST service are going to send HTTP requests (mostly GET’s) to a URI and expect to get some resource in return, usually a blob of XML, probably in a syndication feed format such as ATOM.  From an architectural perspective what this means is that service operations will be inherently more constrained than resources that are freely accessible.  Whether that’s good or bad depends entirely on your point of view.  If you want to design a service that is more tightly locked down, then you’ll most likely prefer a traditional WCF service.  On the other hand, if you want to freely make your data available to clients (especially clients that may not understand or care about SOAP), you would get more bang for your buck with a REST-based service.

Traditional WCF services are also going to allow you a more advanced level of security (for example, message-based or federated security), and can offer reliable messaging and transactional services.  That’s because WCF supports the WS-* SOAP protocols that have evolved over the last several years.  On the other hand, you may not need or want any of those features.  If your client is mainly an AJAX web app, or even a Silverlight rich Internet app, then REST-based services are all you need, and you can benefit from tight coupling with HTTP.

From reading this post so far, you might get the impression that I favor traditional WCF services over REST-based services.  And if we were only talking about a service programming model, you might be right.  But Microsoft has done a lot of work on the client-side programming model for Data Services.  All you have to do for a .NET client is simply write a LINQ query, and Data Services will translate it to a URI sent to the service.  The resulting XML is used to populate client-side entities, which are change-tracked.  Heck, it even supports batch updating and concurrency control. Sweet.  And WCF RIA Services strives for RAD n-tier development for Silverlight apps, with support for end-to-end data validation and a whole bunch of other goodies.  In addition, these higher-order programming models allow you to blend in an operation-based approach by adding methods to your data service.

So I suppose your choice between SOAP and REST services will depend a great deal on the architectural objectives dictated by your application requirements.  Alas, there’s still a role for the architect in all of this. 

Happy Coding