One of the things about Microsoft that can be both good and bad is that people tend to move around a lot. Personally, I really like this quality as it means that there’s always a new set of technologies to learn and always new problems to solve (it reminds me a lot of my consulting days). As such, I wanted to let you know that I’ve moved over to the WCF Web API team – and before you ask, yes, it’s the same team that Glenn is on. 
I’ve been holding off on writing this post for a couple weeks primarily because I’ve been learning a ton about all of the involved technologies and also trying to better understand the divisions of focus – but at least for the current timeframe, I think I’ve got a sense of things. While Glenn continues to drive all things related to the WCF Web API from the API and programming model perspective, I will be working on scenarios around Web API in the context of AppFabric. In case you haven’t taken a look at App Fabric just yet, here are the 2 big ideas (as I naively understand it at this point): 1) you deploy your entire application onto the fabric (along with some declarations related to things like state, etc.) and the fabric will handle deployment onto actual infrastructure nodes as well as scaling, replication, partitioning, etc. Additionally, 2) the fabric provides your application with a bunch of middleware services for things like access control, caching, and messaging.
I believe in the value of Web APIs and in using HTTP as a true application layer protocol and not just a transport to shove SOAP messages through. What I’m sorting through at the moment is how we can take the goodness that Web APIs bring to the table and light up some killer scenarios when those APIs are deployed in App Fabric. There are certainly some relatively obvious scenarios around more granular management based on HTTP semantics such as methods and status codes, but in that I’m still really new to this team and this space, I would really love to get your thoughts and ideas.
I look forward to your thoughts!
