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: 1: using System;
2: using System.Net.Http;
3: using System.Web.Mvc;
4: using FakeChannelExample.Models;
5: using Microsoft.Runtime.Serialization;
6:
7: namespace FakeChannelExample.Controllers
8: {
9: public class HomeController : Controller
10: {
11: private readonly HttpClient httpClient;
12:
13: public HomeController(HttpClient httpClient)
14: {
15: this.httpClient = httpClient;
16: }
17:
18: public ActionResult Index()
19: {
20: var response = httpClient.Get("Person(1)");
21: var person = response.Content.ReadAsDataContract<Person>();
22:
23: this.ViewBag.Message = person.FirstName + " " + person.LastName;
24:
25: return View();
26: }
27: }
28: }
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:
1: using StructureMap;
2: using System.Net.Http;
3:
4: namespace FakeChannelExample
5: {
6: public static class IoC
7: {
8: public static IContainer Initialize()
9: {
10: ObjectFactory.Initialize(x =>
11: {
12: x.For<HttpClient>().Use(() => new HttpClient("http://localhost:31614/"));
13: });
14: return ObjectFactory.Container;
15: }
16: }
17: }
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:
1: [TestClass]
2: public class HomeControllerTest
3: {
4: [TestMethod]
5: public void Index()
6: {
7: // Arrange
8: var httpClient = new HttpClient("http://foo.com");
9: httpClient.Channel = new FakeHttpChannel<Person>(new Person { FirstName = "Joe", LastName = "Blow" });
10:
11: HomeController controller = new HomeController(httpClient);
12:
13: // Act
14: ViewResult result = controller.Index() as ViewResult;
15:
16: // Assert
17: Assert.AreEqual("Joe Blow", result.ViewBag.Message);
18: }
19: }
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:
1: using System;
2: using System.IO;
3: using System.Net.Http;
4: using System.Runtime.Serialization;
5: using System.Threading;
6: using FakeChannelExample.Models;
7:
8: namespace FakeChannelExample.Tests
9: {
10: public class FakeHttpChannel<T> : HttpClientChannel
11: {
12: private T responseObject;
13:
14: public FakeHttpChannel(T responseObject)
15: {
16: this.responseObject = responseObject;
17: }
18:
19: protected override HttpResponseMessage Send(HttpRequestMessage request, CancellationToken cancellationToken)
20: {
21: return new HttpResponseMessage()
22: {
23: RequestMessage = request,
24: Content = new StreamContent(this.GetContentStream())
25: };
26: }
27:
28: private Stream GetContentStream()
29: {
30: var serializer = new DataContractSerializer(typeof(T));
31: Stream stream = new MemoryStream();
32: serializer.WriteObject(stream, this.responseObject);
33: stream.Position = 0;
34: return stream;
35: }
36: }
37: }
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.
