Applications get data from lots of different sources. The most common is to get data from a database or a web service. Typically, we encapsulate calls to a database in a Repository object and we create some sort of IRepository interface as an abstraction to decouple between layers and enable easier unit testing by leveraging faking and mocking. This works great for database interaction. However, when consuming a RESTful web service, this is is not always the best approach.
The WCF Web APIs that are available on CodePlex (current drop is Preview 3) provide a variety of features to make building HTTP REST services more robust. When you download the latest bits, you'll also find a new HttpClient which has been updated for .NET 4.0 as compared to the one that shipped for 3.5 in the original REST Starter Kit. The HttpClient currently provides the best API for consuming REST services on the .NET platform and the WCF Web APIs provide a number of extension methods which extend HttpClient and make it even easier to use.
Let's say you have a client application that is consuming an HTTP service – this could be Silverlight, WPF, or any UI technology but for my example I'll use an MVC application:
using System;
using System.Net.Http;
using System.Web.Mvc;
using FakeChannelExample.Models;
using Microsoft.Runtime.Serialization;
namespace FakeChannelExample.Controllers
{
public class HomeController : Controller
{
private readonly HttpClient httpClient;
public HomeController(HttpClient httpClient)
{
this.httpClient = httpClient;
}
public ActionResult Index()
{
var response = httpClient.Get("Person(1)");
var person = response.Content.ReadAsDataContract<Person>();
this.ViewBag.Message = person.FirstName + " " + person.LastName;
return View();
}
}
}
On line #20 of the code above you can see I'm performing an HTTP GET request to a Person resource exposed by an HTTP service. On line #21, I use the ReadAsDataContract() extension method provided by the WCF Web APIs to serialize to a Person object. In this example, the HttpClient is being passed into the constructor by MVC's dependency resolver – in this case, I'm using StructureMap as an IoC and my StructureMap initialization code looks like this:
using StructureMap;
using System.Net.Http;
namespace FakeChannelExample
{
public static class IoC
{
public static IContainer Initialize()
{
ObjectFactory.Initialize(x =>
{
x.For<HttpClient>().Use(() => new HttpClient("http://localhost:31614/"));
});
return ObjectFactory.Container;
}
}
}
My controller code currently depends on a concrete instance of the HttpClient. Now I could create some sort of interface and wrap the HttpClient in this interface and use that object inside my controller instead – however, there are a few why reasons that is not desirable:
For one thing, the API provided by the HttpClient provides nice features for dealing with HTTP services. I don't really want these to look like C# RPC method calls – when HTTP services have REST features, I may want to inspect HTTP response headers and hypermedia contained within the message so that I can make intelligent decisions as to what to do next in my workflow (although I don't happen to be doing these things in my example above) – this type of workflow is common in hypermedia REST scenarios. If I just encapsulate HttpClient behind some IRepository interface and make it look like a C# RPC method call, it will become difficult to take advantage of these types of things.
Second, it could get pretty mind-numbing to have to create interfaces all over the place just to wrap the HttpClient. Then you're probably going to have to hard-code HTTP knowledge into your code to formulate requests rather than just "following the links" that the hypermedia in a message might provide.
Third, at first glance it might appear that we need to create an interface to facilitate unit testing, but actually it's unnecessary. Even though the code above is dependent on a concrete type, it's actually very easy to fake the data in a unit test. The HttpClient provides a Channel property (of type HttpMessageChannel) which allows you to create a fake message channel which can be leveraged in unit testing. In this case, what I want is to be able to write a unit test that just returns fake data. I also want this to be as re-usable as possible for my unit testing. I want to be able to write a unit test that looks like this:
[TestClass]
public class HomeControllerTest
{
[TestMethod]
public void Index()
{
// Arrange
var httpClient = new HttpClient("http://foo.com");
httpClient.Channel = new FakeHttpChannel<Person>(new Person { FirstName = "Joe", LastName = "Blow" });
HomeController controller = new HomeController(httpClient);
// Act
ViewResult result = controller.Index() as ViewResult;
// Assert
Assert.AreEqual("Joe Blow", result.ViewBag.Message);
}
}
Notice on line #9, I'm setting the Channel property of the HttpClient to be a fake channel. I'm also specifying the fake object that I want to be in the response on my "fake" Http request. I don't need to rely on any mocking frameworks to do this. All I need is my FakeHttpChannel. The code to do this is not complex:
using System;
using System.IO;
using System.Net.Http;
using System.Runtime.Serialization;
using System.Threading;
using FakeChannelExample.Models;
namespace FakeChannelExample.Tests
{
public class FakeHttpChannel<T> : HttpClientChannel
{
private T responseObject;
public FakeHttpChannel(T responseObject)
{
this.responseObject = responseObject;
}
protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
{
return new HttpResponseMessage()
{
RequestMessage = request,
Content = new StreamContent(this.GetContentStream())
};
}
private Stream GetContentStream()
{
var serializer = new DataContractSerializer(typeof(T));
Stream stream = new MemoryStream();
serializer.WriteObject(stream, this.responseObject);
stream.Position = 0;
return stream;
}
}
}
The HttpClientChannel provides a Send() method which you can override to return any HttpResponseMessage that you want. You can see I'm using the DataContractSerializer to serialize the object and write it to a stream. That's all you need to do.
In the example above, the only thing I've chosen to do is to provide a way to return different response objects. But there are many more features you could add to your own re-usable FakeHttpChannel. For example, you might want to provide the ability to add HTTP headers to the message. You might want to use a different serializer other than the DataContractSerializer. You might want to provide custom hypermedia in the response as well as just an object or set HTTP response codes. This list goes on.
This is the just one example of the really cool features being added to the next version of WCF to enable various HTTP scenarios. The code sample for this post can be downloaded here.
