Over the last 3 years, Microsoft has slowly but surely been embracing REST as a programming model for the web in WCF. .NET 3.5 SP1 introduced some REST constructs allowing us to invoke WCF services with HTTP GET/POST/PUT/DELETE verbs in conjunction with UriTemplates. The REST Starter Kit (RSK) was then introduced on CodePlex and this provided many great features including an HTML help page, request interceptors, an HTTP client library, and more. Then WCF 4 was released and some of the features in the REST Starter Kit (e.g., automatic help page) were moved into the actual framework. At this point WCF has gotten much easier to work with and I have blogged in the past showing how simple it is to stand up RESTful services with no svc file and no config. This makes the experience just as easy as building services in MVC but you get richer functionality than MVC provides out of the box with automatic help page and automatic format selection (xml, json, etc.).
At PDC10 last week, the WCF web http team showed that this story is only going to get better – much better. In the presentation "Building Web APIs for the Highly Connected Web", Glenn Block (currently a PM on the WCF team but you might know him from his work with MEF) showed numerous examples of the types of things that we can be expecting to be released in the future. And these features are available right now for you to start playing with – just head over the the WCF site on CodePlex to download the bits. Go ahead – do it now. I have the pleasure of being a member of an HTTP WCF Advisors group organized by Glenn and the one thing I can definitively tell you is that Microsoft is listening. Yes, in the past Microsoft sometimes added features to the .NET framework that we as developers didn't always find useful or simple enough to use. But that is not the case with the WCF HTTP team – if you have a feature you are interested in, go tell them!
One of the key features you'll find in the latest bits are Processors. When the RSK was introduced, it included RequestInterceptors which were incredibly helpful for intercepting the request to get at headers and content of the current request through the HttpRequestMessageProperty type. However, the RequestInterceptors feature did not make it into WCF 4. With the introduction of Processors you'll be easily able to do everything you could do with RSK and more. One of the things that is very easy to do with Processors is to manipulate the format of your requests. For example, in WCF 4 with webHttp you get automatic format selection (between XML/JSON) by adding this to your web.config file:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" helpEnabled="true" automaticFormatSelectionEnabled="true"/>
</webHttpEndpoint>
</standardEndpoints>
</system.serviceModel>
Notice on line #5 above, we turn on automatic format selection. This allows us to pick either XML or JSON by specifying the appropriate value in the Accept header. However, with Processors now, you don't even need this config – in fact, you don't need any XML configuration at all. Instead you can create your own configuration class in C# and specify the JsonProcessor there:
public class MyConfiguration : HostConfiguration
{
public override void RegisterRequestProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
{
processors.Add(new JsonProcessor(operation, mode));
}
public override void RegisterResponseProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
{
processors.Add(new JsonProcessor(operation, mode));
}
}
You can then register this configuration during application start up in your global.asax like this:
RouteTable.Routes.AddServiceRoute<FooResource>("foo/", new MyConfiguration());
There is a "Contact Manager" sample available in the download that shows this functionality. The ability to avoid XML configuration is nice but it's really only part of the story. The real beauty of this is that, since the Processors are extensible, you can add your own processor for ANY format that you want to support from your service – e.g,. xml, json, atom pub, html, png, plain text, etc,. etc.
One of the things that I was most disappointed in when I saw what was put into WCF 4 was the lack of the HttpClient which was introduced in the RSK. Fortunately, it is now back and enhancements are actively being worked on!
Given the huge popularity of jQuery, there is also direct support for sending JSON to the server using C# dynamic typing so you can work with JSON on the server similar to dynamic languages like Ruby.
There is also much more on the horizon – much of which hasn't even been publicly announced yet. This is the time to start checking out what Microsoft is doing to enable HTTP in WCF. Go to http://wcf.codeplex.com/ now – download the bits and tell the team what you think.
