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.

Today we are going to build a neat HTML5 file uploader using ASP.NET Web API and jQuery. We are also going to include knockout.js to keep the list of uploaded files updating smoothly in real time.

In addition to all that, we will leverage on HTML5 drag and drop events , as well as HTML5 File API, to provide the file input to the application. Finally, we will use FormData JS interface to build up the request, and we will use ApiController of our ASP.NET MVC 4 application to pick up the files and save them on the server using an instance of MultipartFormDataStreamProvider.

More after the jump.

So last time around we built together a small p2p chat app using WPF and ASP.NET Web API. Today, we are continuing our experiments with ASP.NET Web API and setting up a simple push (or push-like) messaging system between different apps using self hosting.

In fact, we’ll use one app (“server”) to push out messages to a number of other apps (“clients” or “subscribers”). Even though we have the (in)glorious WCF callbacks at our disposal, I thought it might be fun to try it that way. Hopefully, that sounds interesting, or at least intruiging. In the process we’ll also serialize custom types to JSON using JSON.NET and pass them between self-hosting applications.

More after the jump.

Recently I’ve been really enjoying myself with ASP.NET Web API. It is a tremendous beast, and with it’s self-hosting capabilities, it’s suitable as an HTTP-channeled-communication not only for ASP.NET websites, but also for any other .NET applications. In this post, I’m gonna try to show you the outcome of my weekend mash up - a peer-to-peer WPF chat application (clients connect directly to each other), fueled by ASP.NET Web API.

More after the jump.

Recently, I’ve been playing a lot with ASP.NET Web API, as it is really an exciting technology. It works exceptionally well with JSON.NET (Henrik Nielsen wrote a great post on how to return JSON from ASP.NET Web API using JSON.NET).

However, as it’s been the case in the past with i.e. WCF, I’ve run into a issue with serializing Entity Framework object to JSON when returning them from the ApiController. This is not, by any means, an issue in ASP.NET Web API, as the problem in this case lies in the EF lazy loading, which causes circular reference between the objects. This then throws a corresponding error - “A circular reference was detected while serializing an object of type (…)” if you are using JavaScriptSerializer, “Self referencing loop detected for type (…)” if you are using JSON.NET and so on.

I thought it might be useful to remind about possible solutions to this. There is an easy workaround.

More after the jump.