After ASP.NET Web API was beta-released in February, a number of blog posts came out explaining how to plug Ninject (and other IoC-s, for that matter) to your application through the use of the IDependencyResolver adapter. There was even a NuGet Ninject extension for that (here).

However, these approaches don’t work anymore if you are using the latest ASP.NET Web API (and release candidate) - either from Codeplex source or nightly build packages.

Let’s explore why is that and what you need to do now to be able to use Ninject with ASP.NET Web API.

Routing is the key aspect of every MVC application - after all, it’s how people get to your application, and how search engines see it. As flexible as routing in ASP.NET MVC has been, one would often end up in frustrating situations where more flexibility was needed (or you simply started getting lost in a maze of routes). One of the finest extensions to ASP.NET MVC I have ever worked with is the excellent library AttributeRouting by Tim McCall.

Last month, through the great work of Kamran Ayub, the library has been extended to support ASP.NET Web API, and is now available on NuGet. Let’s have a look at how it can immediately make your life easier and drastically improve the way you handle your routes.

Today’s focus is going to be on message handlers (or, to be precise, DelegatingHandlers) in ASP.NET Web API. If you are familiar with WCF you can surely recall them - used to be called DelegatingChannels at some point - but the purpose has been the same all along, to provide the first (or last, depending whether you look at requests or responses) extendibility point in your Web API applications. You stack up as many message handlers on top of each other as you wish, and the request will travel through all of them.

This, in turn, gives us developers a possibility to process/alter/modify/decline the incoming HTTP request before it reaches the HttpControllerDispatcher. Then, when the controller creates the response, it goes through the same chain of message handlers again, so we can tamper with the response. One example of the applicability of this is that message handlers are a perfect place to address security related matters i.e. integrating OAuth.

The plan for today is to show how DelegatingHandlers are used by building a functionality that checks for an API key on an incoming API request and then logs all requests and responses, thus allowing you to track the usage of your API.

Today we will continue with our favorite topic - ASP.NET Web API. I’ve heard folks asking about how you could easily cache the output of the API methods. Well, in ASP.NET MVC, that’s dead easy, just decorate the Action with [OutputCache] attribute and that’s it. Unfortunately, ASP.NET Web API doesn’t have a built-in support for this attribute.

Which doesn’t mean you can’t have it. Let’s build one

The ASP.NET Web API project progresses at a rapid pace, and has already come a long way since the beta release. And as it is OSS now, it’s really great that we all can see the progress being made (thanks, MS!). So today we are going to build a native HTML5 push notifications mechanism over HTTP protocol, utilizing the latest exciting features of Web API (PushStreamContent), modern browsers’ Server-sent Events EventSource API and, of course, Knockout.js.

Few weeks ago Henrik Nielsen on his blog was kind enough to share some updates about the latest feauters available in the ASP.NET Web API. We are going to be using his sample code as the starting point to develop an application utilizing a real HTTP push messaging infrastructure. We’ll use that to build a browser-based multi-person chat, but the principles showed here could be used for pretty much anything that requires pushing content to the client.

One of the finest news recently has been the announcement of jQuery Mobile Metro theme for WP7. The nice folks at Windows Phone Interoperability Bridges and Sergei Grebnov have released that (also available as a Nuget package) last week.

I immediately thought that this is one of the things that should be definitely checked out - after all jQuery Mobile is a wonderful technology for building robust mobile applications - and jQuery Mobile Metro seems to have so much potential! Coupled with Apache Cordova (formerly PhoneGap), it allows us to quickly and easily brew a mobile application that can be deployed to any platform. What happens with Cordova, is that you build your application with HTML5, CSS and Javascript - and then it’s packaged into an environment specific package and run as if it was a native application (using an embedded browser control). Things couldn’t be any easier.

So today, the plan is to build a sports application for Windows Phone 7 - using all the goodies: Apache Cordova, jQuery Mobile Metro and our good friend, ESPN API.

Let’s say you have a model and want to serve it through a different MediaTypeFormatter from different controllers or routes or urls? You want same content type (MediaHeaderValue) request, to be formatted differently in different situations - how could you do that, if everything resides in GlobalConfiguration?

It would be perfect to be able to use per-controller configuration in ASP.NET Web API. Unfortunately, at this stage, this feature is not yet supported. Henrik mentioned that Mike Stall is currently working on this, and it will be supported in the full release on Web API (perhaps even earlier, on codeplex?).

Anyway, let’s take this idea for a spin and explore what we could do in beta version of ASP.NET Web API, because we could still vary our formatters and responses.

Today we are going to build a custom formatter for ASP.NET WebAPI, deriving from MediaTypeFormatter class. It will return our model (or collection of models) in RSS or Atom format.
The Formatter is supposed to react to requests sent with request headers “Accept: application/atom+xml” and “Accept: application/rss+xml”.

Let’s get going.

I recently got a bit depper into Bing Maps development, and I have been mesmerized by their richness and capabilities.

With that said, I had an idea that Bing Maps are one of those products that are simply tailor made for full screen viewing. So I thought, why not bring that to life with the new HTML5 Full screen API? Noteworthy, Facebook recently rolled out an update including the full screen API in their photo viewing service.

More after the jump.

I was really excited when I heard the announcement of the ESPN API. Being a sports freak like me, that opens a tremendous amount of possibilities for application development. Today, let’s build our own sports news single-page application, fueled entirely by Knockout.js.

You will be able to browse the latest news from ESPN from all sports categories, as well as filter them by tags. The UI will be powered by KnockoutJS and Twitter bootstrap, and yes, will be a single page. We have already done two projects together using knockout.js - last.fm API infinite scroll and ASP.NET WebAPI file upload. Hopefully we will continue our knockout.js adventures in an exciting, and interesting for you, way.

More after the jump.