WCF and MySpace: a RESTful MIX session!
We just recently published a list of sessions for MIX08.
Among those, there is one that I hold especially dear:
I had the luck to work with Paul, his team and the WCF team in the last months, specifically on how to leverage the web capabilities that WCF acquired in the version 3.5 of the framework.
It was really a great experience! First, because I had a great time with the MySpace guys. Second, because it was the best way for me (fairly open minded, but still a WS-* veteran operating at WS-Trust level) to approach the REST side of the house. The no-nonsense approach of Paul and his team, who wanted to use REST principles for getting the job done rather than for “religious” reasons, helped me to frame the principles behind REST and ROAs according to their actual usefulness. It basically helped me to cut to the chase, filtering out all the rhetoric (inevitable when things get polarized into camps). And you know what, I have to admit that I actually kind of like it 🙂 That’s why I think that this session will be truly remarkable: you will see a paradigmatic application of REST design principles on a real world API, something so big that it needs to be well designed for working as expected. Can you find a better validation of the soundness of the REST principles? And of course, the fact that the web features of WCF supports all that is a source of huge pride for all the people that worked on it…
Anyway: I won’t give away any details here. My strong advice: if you go to Mix, you can’t miss Paul’s session!
I hope I can make it to mix this year if only to see this session.
I experimented with using WCF to do a restful API a while back but ultimately abandoned it because I thought it would be better built using an MVC framework (take your pick Rails, MonoRail, System.Web.MVC) than WCF.
I’ll be interested to know what advantages WCF can provide over the MVC route.
Chris, that’s a great question. It makes we want to turn it around and ask what advantages the MVC factoring has over the WCF factoring given equivalent functionality.
The way I see it, there are two world views rapidly trending towards the same middle ground. On one side, we have the services folks who have been builing components/services for a long time. These guys are long-tailing towards reach protocols like plain HTTP because it makes their services accessable to more clients. On the other side, we have the web folks who have been building content-driven presentation layers for a long time and are now realizing that returning structured data in addition to HTML/images/CSS/script can be quite interesting.
As a result, you have a situation where depending on what world view they’re affinitized to, one group of people will look at a problem and see services and another group will look *at the exact same problem* and see web pages. And they will both be right, from a certain point of view.
An interesting pivot here is how the state model for the UI differs (or does not differ) from the state model of the “service”. For stateless services that primarily respond to HTTP GETs (i.e. idempotent data retrieval operations), the choice is largely aesthetic. If you view these things as just another type of content your website returns, you’re likely to be happier using something like MVC. If you view these things as idempotent services that your application exposes, then you can use WCF.
A major selling point of WCF is that it lets people who have already adopted a “services” mindset use a single programming model to build those services, regardless of the underlying protocol details. MVC has a different pitch; it lets people who are used to building content-driven sites stretch those techniques beyond simple HTML into the structured data world. These two technologies will inevitably meet in the middle.
It gets interesting when you move beyond idempotent operations and into the world of state management. MVC frameworks are really tuned for the stateless case. Services (particularly workflow services) are good at managing long-running user state that lives beyond a particular browser session. In those cases you can either front your services with an MVC controller, or expose your services to the outside world directly.