Web API Preview 5 Is Now Available

Today, Glenn is announcing at the BUILD conference that Web API preview 5 is available both on CodePlex and Nuget.  If you’ve been following the project for while, you’ll note that we went through a dry spell there for a while regarding updates.  This was due primarily to the level of manual effort involved in updating our bits.  Fortunately, we recently automated away all of that manual effort and are excited to get you new bits (and excited about getting bits to you much more frequently going forward). Here is a high level list of what you can expect to see in preview 5 as well as some notable changes.

New Features/Enhancements

  • OData Formatter
  • Dependency refactoring from host common code
  • Support for Batch with mime/mixed content where every part has a full Http request
  • Web API code-based configuration (simplifications)
  • Web-based test client for WCF Web API
  • Http File upload
  • Refactored formatters
  • Better IoC support
  • Additional samples for specific features such as file upload
  • Content negotiation now supports qualifiers
  • ActionOfStreamContent – Enables accessing the raw content stream
  • New HttpMemoryBinding to enable in-memory hosting and invoking of Web APIs

New Prototype Features (on WebAPI-Prototype branch)

  • WebApiConfiguration includes conventions for WebGet/WebInvoke
  • WebApiRoute provides better side by side integration with MVC routes
  • MapServiceRoute extension method simplified registration and usage of WebApiConfiguration
  • SetDefaultHttpConfiguration / GetDefaultHttpConfiguration extension methods enable the getting and setting of a global configuration object that will be used by default by MapServiceRoute unless a specific one is provided
  • MediaTypeFormatterCollectionExtensions.AddRange enables a more compact way to add formatters
  • FormUrlEncodingMediaTypeFormatter
  • Task<T> for Web API operations and sample

Breaking Changes

  • DelegatingChannel renamed to DelegatingHandler
  • HttpChannel renamed to HttpMessageHandler
  • FormUrlEncodingMediaTypeFormatter and JsonValueMediaTypeFormatter were moved from the default branch to the WebAPI-Prototype branch as they are not currently part of the core product source
  • DelegatingHandler no longer require passing in a channel in the constructor making it more friendly to inversion of control (IoC) containers
  • New constructor overload on HttpMessageHandlerFactory overload which accepts a Func<IEnumerable<DelegatingHandler>> to allow user code or IoC containers to construct handlers.
  • IQueryable previously supported case-insensitive matches on operators. In the current drop we only will match on lowercase operators i.e. “$top” but not “$Top”. According to the spec this is correct behavior however we could relax it in the future.


Like I mentioned above, preview 5 is also being released on Nuget today. Here’s the breakdown of the Nuget packages that will be available:

  • HttpClient– like it sounds, this gives you the HttpClient object model, which can be used by both the server and the client for a symmetric Http programming experience.
  • JsonValue– Contains JsonValue api for typeless / dynamic access to Json.
  • WebApi– The server-side object model for Web API
  • WebApi.All– preserved for backwards compatibility; basically just pulls in everything.
  • WebApi.Core– preserved for backwards compatibility; pulls in WebApi.0.5.0
  • WebApi.Enhancements– gives you the Web API core product code plus the enhancements library (from the prototype branch)
  • WebApi.OData – enables returning OData from a Web API.

In addition to the core Nuget packages, we’re also pushing up a set of symbol packages so that you can more easily debug through Web API source code.

  • HttpClient.0.5.0.symbols.nupkg
  • JsonValue.0.5.0.symbols.nupkg
  • WebApi.0.5.0.symbols.nupkg
  • WebApi.Enhancements.0.5.0.symbols.nupkg
  • WebApi.OData.0.5.0.symbols.nupkg

Updated Content

In addition to updating the source code and binaries, we’ve pushed up a more current set of getting started material, including both information on getting started with the core product bits and information on getting started using the Http enhancements library on the prototype branch.  There’s even this video on how to take advantage of our built-in test client.

Navigating Our CodePlex Repository – the WebAPI-Prototype branch

One thing that we wanted to improve with this push was a more clear view of what was product code and what was prototype or proof-of-concept code.  Therefore, we created a ‘WebAPI-Prototype’ branch and pulled all non-product code (which translates into all code that is not checked into our internal source control) out of the default branch and into the prototype branch.


This structure provides 2 main benefits:

  • As mentioned above, better transparency between supported product bits and proof-of-concept bits
  • By having the default branch be a reflection of our internal repository, we can update it much more frequently because we won’t have to account for any changes that would have happened outside of our internal repo.One thing to note about the introduction of this branch is that samples currently live in the prototype branch – so if you want to use the samples as a way to get started building with Web API, you’ll want to update to the prototype branch.  That said, there are samples that exist in the ‘Tests/*/Scenarios’ folders.  For example, the Mime multipart sample can be found at ‘Test\Microsoft.Net.Http.Formatting\Scenarios\MimeMultipart’.

As you can see, we’ve added a lot of new goodness with preview 5 and are excited to have you test-drive the bits and let us know what you think.  And again, now that we’ve automated the process of getting our code pushed to CodePlex, expect to see updates coming regularly.

About Howard Dierking

I like technology...a lot...
This entry was posted in WCF, Web, Web API. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Amit Patel

    Great job..

  • Pingback: Jon talks ASP.NET MVC 4, ASP.NET 4.5, ASP.NET Web Pages 2, and Visual Studio 11 on Jesse Liberty’s “Yet Another Podcast” « Ocr Software « OCR Software

  • Pingback: Our ComponentOne | Blog | GANG Nov 2011 Recap

  • Anonymous

    It depends on whether you want authentication to be completely transparent to your service operations or whether you want to control how individual operations are secured as I did with http://codebetter.com/howarddierking/2011/10/11/oauth-2-0-in-web-api/.  If you want complete transparency, you should be able to do this with just a message handler.  If you need info from the service operation, you’ll probably need both a message handler and an operation handler.

  • John Waters

    What is the recommended approach right now to hooking up authentication (http header leve) to WebAPI? 

  • Pingback: Jon talks ASP.NET MVC 4, ASP.NET 4.5, ASP.NET Web Pages 2, and Visual Studio 11 on Jesse Liberty's "Yet Another Podcast" - Jon Galloway

  • Andy Pook

    Good job. We are using these bit internally right now :)
    Great to hear that you will be able to iterate (to us) more quickly.
    I have noticed in the current bits a move to using concrete types in the API. ie Collection replacing ICollection or IEnumerable. The thread I’m pulling here is the recent changes to support the new HttpErrorHandler in HttpConfigurationBehavior.
    I realize that this may not be a brilliant example as HttpConfigurationBehavior is internal. However,  it worries me that this approach might creep into the public API. 

    There are have been many times where I have been prevented from making customizations (on the BCL or wider .Net framework) because concrete types have been exposed rather than appropriate interfaces. Or blocked due to internal or sealed classes that are simple enough to not be protected by the “increasing the testing matrix” reason.

    Secondly the there are some commonly used interfaces (like WebApiConfiguration, HttpConfiguration) that are confusing (at least to me :) ) because different techniques are used to expose, what look like similar things. eg MessageHandlers is a simple collection (again with the concrete types) that you can add to. While ResponseHandlers and ErrorHandlers take delegates suggesting a more factory based approach. There is also a MessageHandlerFactory to go with MessageHandlers.

    I think I’ve figured out the interaction of the various bits but it took some code spelunking and head scratching.

    This is no way intended as a dig at you guys. This is exactly the kind of project that helps make my life easier and opening the komono to the public is brave.
    Either we’ll make this thing more shiny or I’ll learn something. Both good things.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #939