SOAP? REST? Whichever you choose, WCF is the right framework

There's a new paper by David Chappell that is worth checking out.  Entitled "Dealing with Diversity: Understanding WCF Communication Options in the .NET Framework 3.5", it discusses WCF and its applicability to REST as well as WS-* style communications.  (To get the paper, click the link and then scroll down to download the Diversity paper.)

As you may know, there's been lots of discussion about whether SOAP-based or REST-style approaches to services interfaces are the right thing. 

If you're not familiar with the debate, here's the plot summary: that REST-style interfaces can be useful in basic scenarios, but if services-based applications demand things like reliabilility, transactions, forwarding, or message-based security, then SOAP with the comlpementary WS-* family of standards is probably a better approach.  (Regarding REST, a secondary point is that many people say REST when what they mean is HTTP QUERY, and the two are different things.  See my note below on Amazon SQS.)  

But that's my take.    Not everyone will agree with that summary.  I guess a safer, but not purely controvery-free statement might be:  REST and SOAP will be useful in different scenarios, for different audiences.

It's an interesting debate, and probably not one that will settle clearly for a while.  Our philospohy at Microsoft is that, whichever protocol you choose, REST, SOAP or otherwise, if you are building applications on Windows, WCF is the right programming framework.  WCF is the Windows Communication Foundation; it is part of the .NET Framework, and is the generalized communicoation programming framework within .NET.  If you are building an application that communicates with other systems, whether those other systems run on Windows or not, whether the communications are outbound or inbound with respect to the part you are building, WCF is for you!   Due to previous marketing focus on SOAP and WS-* support around WCF, many people who are conversationally familiar with WCF mistakenly believe that WCF is a programming framework that solely helps people build WS-* applications, or applications that speak SOAP.   That is true: WCF does help you build apps that do WS-* ,  but the statement is incomplete.   A more complete statement is: WCF helps people build apps that communicate.

Whether you choose a binary transport that is optimized for communication between  .NET endpoints, or SOAP and angle brackets, or a REST-style communications endpoint that uses JSON for the data format, or an RSS feed, or something else, WCF is the right programming framework. (Special note!!  The REST and JSON and RSS stuff in WCF was added in the .NET Framework v3.5, which is set to release this month (November 2007))   Using WCF, you can even create a single service with multiple services interfaces, each of which uses a different protocol and serialization format. 

Sidenote: speaking of multiple interfaces for the same resource, check out what Amazon did with SQS: there is a REST interface, a SOAP interface (described in WSDL) and a QUERY interface. The REST interface is bona-fide REST. It uses HTTP verbs like (GET DELETE PUT POST), and the URI corresponds or maps to the resource in question, for example the queue you'd like to operate on. In WCF, to build this sort of interface, you would use a [WebInvoke] attribute on your service interface. The QUERY interface on the Amazon SQS resource is, like the REST interface, always based on HTTP, but QUERY is different than REST in that QUERY is always an HTTP GET, and specifies the object and verb in the URI.


The QUERY request to create a queue:

GET /?Action=CreateQueue&QueueName=Foo HTTP/1.1



The REST request to create a queue:

POST /?QueueName=Foo HTTP/1.1


Some people confuse or conflate REST with HTTP QUERY, but Amazon certainly does not. It doesn't help matters that there is no widely accepted or adopted name for the HTTP QUERY services interface. Amazon calls it HTTP QUERY or just QUERY but as far as I am aware, that name is not widely used by other systems who expose similarly architected interfaces.

This is what I mean when I say that WCF is a generalized communications framework.  It is not WS-* only.  WCF supports different protocols, different data formats, different models, all within a single generalized communications framework.   

David Chappell makes this point very well in his paper.  It's worth checking out.