Using WCF for REST, Part 2
In part one of this series, I listed several websites and blogs that had useful information on the Windows Communication Foundation (WCF) and REST. I also mentioned that if I was stating again, I’d probably use something other than WCF. Perhaps deriving my own REST server from System.Net.HTTPListener, for example.
Vish asked for some additional details in his comment to that post. He works on the Microsoft WCF development team and was curious about our experience.
I had just begun putting together my response when I noticed Scott Guthrie’s post about Service Pack 1 for the .NET Framework 3.5 beta release. Steve Maine also posted specifics about the ADO.Net Data Services and WCF changes.
So, Vish, it seems your team’s beaten me to the punch on some of these issues! Many of the difficulties I was having with WCF and REST were addressed by the service pack. Here’s an overview of our key stumbling blocks:
- REST requires much greater control over the URI than SOAP does, and the URITemplate class just wasn’t up to the task. We had to hardcode most of our endpoints to compensate. (Fixed in SP1. Hooray!)
- Supporting multiple formats, such as serving both XML and JSON, either require you to program against Stream or require twice the number of endpoints.
- Existing serializers had trouble with complicated object graphs, forcing us to perform serialization/deserialization ourselves. (This seems greatly improved in SP1.)
- WCF allows only one contract/interface per endpoint. This makes it tricky to factor out common contract patterns.
- Good REST practice would have you return many kinds of errors as HTTP status messages. SOAP embeds all error information in the returned XML. WCF is closely aligned with the SOAP approach, which means that you’ve got to be very careful distinguishing exceptions from faults when implementing REST in WCF. It was an unpleasant surprise, and we had to do quite a bit of work to deal with that.
I’ll talk about all five of these areas in more detail in upcoming posts in this series. And I’ll be sure check out the SP1 beta once we get our Infovark Alpha release out the door.
Steve Maine said,
Wrote on May 18, 2008 @ 5:16 am
Thanks for posting this! I’m looking forward to reading more about your experiences as they all sound like good issues.
I’m interested in all of them, but (4) is the one that piques my curiosity the most. What kind of factoring patterns would you like to be able to do, but can’t? To what degree does the single-implementation-type-per-service restriction play in here?
-smaine
Dean said,
Wrote on May 21, 2008 @ 10:52 pm
Hey Steve, glad you stopped by. I’ve found Brain.Save() very useful for getting a handle on this WCF stuff.
I started writing an explanation of #4, but it was too long for a comment. I’ll get a post up soon about our REST design.
Using WCF for REST, Part 3 « Infovark Underground said,
Wrote on May 27, 2008 @ 3:44 pm
[...] easiest way to explain the issues we encountered when implementing REST is to work through the design principles we followed. I think much of our trouble came from the [...]
Rinsing the SOAP from WCF (or, RESTful WCF Hyperlink Acupuncture) | The Freak Parade said,
Wrote on August 28, 2008 @ 10:32 pm
[...] WCF for REST, Part 1, Part2 and Part 3. Make sure you read all the comments though, several of the gripes brought up in these [...]