Recently, I’ve been working a little on an application that allows users to save, tag, bookmark links for later reading - that kind of stuff. Obviously, Web API facilitates those types of apps really well, as data can be exposed in a magnitude of formats. So I had this crazy idea - CLR to Kindle? Why not.

Unfortunately MOBI format (used by Kindle) is not that easy to support from C#, as to my knowledge there is no ready-made DLL port or SDK available. On the other hand, Amazon has created a proprietary tool called [Kindlegen][1], which is a command line tool, and allows you to convert HTML into MOBI. We’ll use that - it’s a hacky solution but it sure is a lot of fun.

A while ago I blogged about [supporting BSON][1] at your Web API end points. A good alternative to both JSON and BSON has, for quite a while now, been [MessagePack][2].

The main problem with supporting MessagePack in your Web API has been the fact that MessagePack required a strongly typed serializer (in other words, you needed to tell the serializer what type you serialize and deserialize at compile time). There was no easy way to provide support for boxed objects (untyped context) - and Web API media type formatters run against such generic object instances. In face, to be precise, writing to a stream (serializing) has never been a big problem, but reading was very complicated. An easy solution was a type whitelist and a massive if-else block, but such approaches are hardly good ideas.

Four days ago, Yusuke Fujiwara, one of the wizards behind MessagePack for CLI, [added support][3] for untyped serializer factory, effectively inviting all of us to start using MessagePack in Web API.

Azure Mobile Services is the latest cool thing in town, and if you haven’t checked it out already I really recommend you do, i.e. in this nice introduction post by Scott Gu. In short, it allows you to save/retrieve data in and out of dynamic tables (think no-schema) directly from the cloud. This makes it a perfect data storage solution for mobile apps, but why not use it in other scenarios as well?

For now Azure Mobile Services (a.k.a. ZUMO) is being advertised for Windows 8 only (the SDK is targeted for Windows 8 applications), but there is no reason why you couldn’t use it elsewhere.

Let’s do that and use Web API as a proxy.

It’s been 2 weeks since Web API has been released, and in a post highlighting the changes, I mentioned I will write an updated tutorial on file upload.

File upload is quite an important topic for Web API endpoitns or for API-driven applications, and sure enough there are some nice changes to the MultiPartFormDataStreamProvider, which, contrary to its versions in the Beta and RC allow easy and flexible model for dealing with uploaded data. On the other hand, these changes between Beta-RC-RTM, mean many of the upload-related posts found in the Web API community (this blog included) no longer work properly.

Let’s have a look at how you could now upload files to your ASP.NET Web API.

OData support in Web API is arguably one of its hottest features. However, it’s support in Web API has been a bumpy ride - initially, OData was supported in a limited way only, and ultimately ended up being yanked altogether from the Web API RTM. It is however stil lpossible to use OData with Web API, only in a slighly different form , as an [external NuGet package][1], which, in its pre-release alpha format was published last Wednesday, along the Web API RTM release.

This package is called Microsoft ASP.NET Web API OData and is a joint effort by Microsoft’s Web API and OData teams. Alex James has written a [great introduction][2] to the package, so I recommend reading it.

In the meantime, let me show you how to add $inlinecount support as for the time being, it’s still not provided there out of the box.

If you have been following this blog for a while now (and if not, I really hope you will!), you’d know that I am a big fan of Web API. I have been blogging a lot about Web API, through its beta, RC stages and even about features that were only available through the Codeplex builds and I have to say that it is a terrific bridge between CLR and HTTP and fits really nicely into the existing landspace of web technologies.

With that said, today is a really big and important day, as Web API has been publicly released in its RTM version. This effectively means that you have binaries you can safely use in production scenarios and take advantage of all the great features of the framework. You can [download MVC4 (including Web API) RTM here][1].

Let’s go through the new features in RTM.

The question that often comes up when talking to developers and clients about Web API solutions is how exactly should you go about testing your route configuration in Web API? Some would perhaps argue that in certain cases, especially if you stick to RESTful approach, this type of testing wouldn’t even be necessary, because the convention over configuration provided by the framework means that you effecitvely end up testing something that’s internal working of Web API.

With that said, especially when you have complex routes, or when you break the Restful approach and provide RPC-style API, or if you have your API actions decorated with HTTP verbs that don’t match the action names, you probably want to (and probably should, if you ask me) test the API routing to make sure certain requests end up in proper places.

Let’s deal with this interesting problem.

Just like last time, when we discussed observable arrays, I wanted to share a few (hopefully) useful tips about working with templates in Knockout. This is not going to be a comprehensive look into templating with knockout - there are plenty of resources that cover that - but rather a collection of smaller pieces of advice that could make you life easier.

Again, familiarity with Knockout is assumed.

I am currently working on an MVC4 project that allows users to authenticate through OpenID. I don’t think I need to convince anyone about the benefits for both parties that come with that. Users don’t have to register at your site, and you have less of those tedious account maintance tasks.

Although it’s apparently coming later on as a built-in feature into the Visual Studio templates (Damien Edwards showed that stuff for Web Forms during aspConf), let me show how you can very quickly add simple OpenID support to your MVC4 application.

More after the jump.

Recently, I have been blogging mainly about Web API, but many people have been asking me about Knockout.js. And rightfully so, because it is one of the most robust Javascript client side technology right now.

I blogged about KO a couple of times here before, but I thought it might be a nice change to do it in a new format. Instead of a one big, end-to-end solution, let’s do a set of “pro tips”, small pieces of real-life advices for your Knockout solutions.

This article assumes a working knowledge of Knockout.