Web API 2 introduced the new interface IHttpActionResult to return back REST responses, where Web API 1 was using the class HttpResponseMessage to represent HTTP response, and HTTPResponseException to represent HTTP response error.

IHttpActionResult allows developers to enhance their Web API 1 code to be :

  1. More testable.
  2. More reusable.
  3. Cleaner, and more elegant.

We are going to unleash the potential of this interface and see some creative ideas on how to use it.

Start from HTTP Protocol

First of all, let’s see what Web API is trying to do, and let us look at the HTTP response. A usual responses coming from a web server look like:

HTTP/1.1 200 OK
Cache-Control: max-age=1200
Content-Length: 10
Content-Type: text/plain; charset=utf-16
Server: Microsoft-IIS/8.0
Date: Mon, 27 Jan 2014 08:53:35 GMT

hello

This is a successful response, which we can know from the code 200.
Another example of a failed response:

HTTP/1.1 404 Not Found
Content-type: text/html
Content-length: 47
  
Sorry, the object you requested was not found.


The traditional thinking of Web API 1

Web API 1 introduced HttpResponseMessage, and by looking at the class properties in the picture down, you can see it is a literal .NET representation of the HTTP response.

states

By using HttpResponseMessage we can craft any HTTP response we want. For example to create the HTTP response mentioned above:

var response = new HttpResonseMessage(HttpStatusCode.OK);
response.Content = new StringContent("hello");
response.Content.Headers.ContentType = new MediaTypeHeaderValue("text/plain");
response.Headers.CatcheControl = new CacheControlHeaderValue {MaxAge = TimeSpan.FromMinutes(2)};

One problem with the code above is that it is ignoring the request, and the request content type, and this is why most of the time we will create the response like this:

var response = request.CreateResponse(HttpStatusCode.OK, new StringContent("hello"));
response.Headers.CatcheControl = new CacheControlHeaderValue {MaxAge = TimeSpan.FromMinutes(2)};

By using request.CreateResponse, Web API will create the response with content type requested by the request.

Worth mentioning alternatives

Before we move to Web API 2, it is worth mentioned that Web API 1 provides some built-in translation from any object type to HttpResponseMessage. For example, all these are valid return types of a Controller action:

void Post()
IEnumeration<string> Get()
string Get(int id);
MyCustomClass Get(int id);


Web API will serialize the object returned and wrap it in a successful HttpResponseMessage with status code 200.
And in the case of void, the Web API return  204 No Content 


Web API 2 and IHttpActionResult

To see the advantages of this interface, let us check an example in the version 1, and see its translation into version 2.

public class ProductsController : ApiController
{
    IProductRepository _repository;
    public ProductsController(IProductRepository repository)
    {
        _repository = repository;
    }
    public HttpResponseMessage Get(int id)
    {
      try {
        Product product = _repository.GetById(id);
        if (product == null)
        {
            return Request.CreateResponse(HttpStatusCode.NotFound);
        }
        var response = Request.CreateResponse(product);
        // add more code for caching and other custom response headers...
        // for example: 
        response.Headers.CatcheControl = new CacheControlHeaderValue {MaxAge = TimeSpan.FromMinutes(1)};
        return response;
      }
      catch (Exception ex) {
        return Request.CreateResponse(HttpStatusCode.InternalServerError);
      }
    }
}

The problems with previous code are:

  1. The class is responsible of calling repository and creating the HttpResponseMessage.
  2. There is no easy way to re-use code that set response header, like the caching for example.

Let us rewrite the code using IHttpActionResult:

public class ProductsController : ApiController
{
    IProductRepository _repository;
    public ProductsController(IProductRepository repository)
    {
        _repository = repository;
    }
    public HttpResponseMessage Get(int id)
    {
      try {
        Product product = _repository.GetById(id);
        if (product == null)
        {
            return NotFound();
        }
        return Ok(product);
      }
      catch (Exception ex) {
        return InternalServerError(ex);
      }
    }
}

Where Ok, NotFound, InternalServerError are ApiController methods that are returning concrete implementation of IHttpActionResult.
Web API already comes with a library of classes that implement this interface which represent the most used responses on the web like : Ok, NotFound…, and they are located in the library system.web.http.results.

The benefits of using the previous code are:

  1. Separation of concerns.
  2. Better testability.
  3. Produce reusable code.


1. Separation of concerns

The code that produce the HttpResponseMessage is separate, and we can implement our own generation of the response message, and our controller concern only on retrieving the data from the repository.


2. Better testability

Let us write test code for the previous code:

[TestMethod]
public void GetReturnsProductWithSameId()
{
    var mockRepository = new Mock<IProductRepository>();
    mockRepository.Setup(x => x.GetById(3))
        .Returns(new Product { Id = 3 });

    var controller = new ProductsController(mockRepository.Object);

    IHttpActionResult actionResult = controller.Get(3);
    var contentResult = actionResult as OkNegotiatedContentResult<Product>;

    Assert.IsNotNull(contentResult);
    Assert.IsNotNull(contentResult.Content);
    Assert.AreEqual(3, contentResult.Content.Id);
}

Obviously, testing is easier because we are testing the business logic which is retrieving data, and not generating the Http Response.


3. Produce reusable code

Let us write the code that add the cash repose header to the response.

In order to do that, I will borrow this brilliant idea of using chaining IHttpActionResult together to write reusable Http Response Headers.
Let us create a code that implement IHttpActionResult and crate a response header for cashing:
(P.S: I am borrowing his code, but just make it simpler)

public class CachedResult<T> : IHttpActionResult where T : IHttpActionResult
{
    public T InnerResult { get; private set; }
    public CachedResult(T innerResult)
    {
      InnerResult = innerResult;
    }

    public async Task<HttpResonseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = await InnerResult.ExecuteAsync(cancellationToken);
        response.Headers.CacheControl = new CacheControlHeaderValue
        {
          MaxAge = TimeSpan.FromMinutes(2)
        };
        return response;
    }
}

The above code will take an IHttpActionResult in the construction and add a caching header to it. To use it, we can do the following code:

var responseOk =  Ok(product);
var cachedResult = new CachedResult<System.Web.Http.OkResult>(responseOk);

Or we can do better, by creating an extension method to the IHttpActionResult, like this:

public static class HttpActionResultExtensions
{
  public static CachedResult<T> Cached<T>(this T actionResult) where T : IHttpActionResult
  {
    return new CachedResult<T>(actionResult);
  }
}

And now we can use it as follows:

var responseOk =  Ok(product).Cached();

The Chached extension method can be reused whenever we want to add Cache response header to the HttpResponseMessage