Clemens Vasters has written two interesting atricles on building RESTful services using Indigo Windows Communication Foundation entitled Teaching Indigo to do REST/POX, Part 1 and Teaching Indigo to do REST/POX, Part 2. His first articles begins
A little bit more than half a year ago I got invited to a meeting at Microsoft in Redmond and discussed with Steve Swartz, Yasser Shohoud and Eugene Osovetsky how to implement POX and REST support for Indigo. ... I witnessed the definition a special capability for the HTTP transport that I am exploiting with a set of Indigo extensions that I’ll present in this series of blog posts. The consensus in the meeting was that the requirements for building POX/REST support into the product weren’t generally clear enough in the sense that when you ask 100 people in the community you get 154 ever-changing opinions about how to write such apps. As a consequence it would not really be possible to define a complete programming model surface that everyone would be happy with, but that a simple set of hooks could be put into the product that people could use to build programming models rather easily. And so they did, and so I did. This new capability of the HTTP transport first appeared in the September CTP of Indigo/WCF and surfaces to the developer as properties in the Message class Properties collection or the OperationContext.Incoming/OutgoingMessageProperties. If you are using the Indigo HTTP transport on the server, the transport will always stick a HttpRequestMessageProperty instance into the incoming message properties, which provides access to the HTTP headers, the HTTP method (GET, POST, PUT, etc.) and the full query string. On the client, you can create an instance of this property class yourself and stick it into any outbound message’s properties collection and, with that, control how the transport performs the request. For sending replies from the server, you can put a HttpResponseMessageProperty into the message properties (or, again, into the OperationContext) and set the HTTP status code and description and of course the HTTP reply headers. And since I have nothing better to do, I wanted to know whether this rather simple control feature for the HTTP transport would indeed be enough to build a POX/REST programming model and application when combined with the rest of the Indigo extensibility features. Executive Summary: Yes.
A little bit more than half a year ago I got invited to a meeting at Microsoft in Redmond and discussed with Steve Swartz, Yasser Shohoud and Eugene Osovetsky how to implement POX and REST support for Indigo. ... I witnessed the definition a special capability for the HTTP transport that I am exploiting with a set of Indigo extensions that I’ll present in this series of blog posts. The consensus in the meeting was that the requirements for building POX/REST support into the product weren’t generally clear enough in the sense that when you ask 100 people in the community you get 154 ever-changing opinions about how to write such apps. As a consequence it would not really be possible to define a complete programming model surface that everyone would be happy with, but that a simple set of hooks could be put into the product that people could use to build programming models rather easily.
And so they did, and so I did. This new capability of the HTTP transport first appeared in the September CTP of Indigo/WCF and surfaces to the developer as properties in the Message class Properties collection or the OperationContext.Incoming/OutgoingMessageProperties.
If you are using the Indigo HTTP transport on the server, the transport will always stick a HttpRequestMessageProperty instance into the incoming message properties, which provides access to the HTTP headers, the HTTP method (GET, POST, PUT, etc.) and the full query string. On the client, you can create an instance of this property class yourself and stick it into any outbound message’s properties collection and, with that, control how the transport performs the request. For sending replies from the server, you can put a HttpResponseMessageProperty into the message properties (or, again, into the OperationContext) and set the HTTP status code and description and of course the HTTP reply headers.
And since I have nothing better to do, I wanted to know whether this rather simple control feature for the HTTP transport would indeed be enough to build a POX/REST programming model and application when combined with the rest of the Indigo extensibility features. Executive Summary: Yes.
One of the first work items I got assigned when I joined my current team at MSN Windows Live was responsibility for our Indigo migration. This was pretty ambiguous and it turned out this was a place holder work item for "Figure out why we should move to Indigo and when". So I talked to our devs for a while and after thinking about where I saw our services evolving it seemed there were two main things we wanted from Indigo; better performance and support for a more diverse view of what it meant to be a Web service.
Why we need better performance is pretty straightforward. We provide services that are depended on by hundreds of millions of users across a variety of MSN properties including Hotmail, MSN Messenger, and MSN Spaces as well as newer Windows Live properties like Windows Live Favorites and Windows Live Fremont. The more performance we can squeeze out of our services stack, the better things look on our bottom line.
Then there is support for a broader view of what it means to be a Web service. When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world's best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn't jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren't the only Web service on the planet. Technically they aren't even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0. I remember sending mail to a number of folks on the Indigo team about this disconnect including Doug Purdy, Don Box, Steve Swartz and Omri Gazitt. I remember there being some initial resistance to my feedback but eventually opinions started to thaw and today I'm glad to read posts where Doug Purdy calls himself one of the original REST-heads in the big house.
Anyway, the point is that there is more than one way to build services on the Web. Services frameworks like Indigo Windows Communication Foundation need to support this diverse world instead of trying to shove one solution down the throats of their customers. We at Microsoft now understand this, I hope eventually the rest of the industry does as well.