Regardless of what kind of applications you build with Web API, you are bound to write a lot of similar code in many of your actions - to check if the model is valid and to check if the submitted object is null.

This creates unnecessary noise and repetition. In this short blog post, let’s have a quick at how you can delegate this kind of repetitive logic to Web API filters.

More after the jump.

Few weeks ago, I blogged about using Azure Mobile Services in your Web API applications and I think I managed to convince some of you that ZUMO with its REST-style API is really useful and super easy to work with.

The guys at Azure Mobile Services are not slowing down at all. Today Scott Gu announced a whole new super cool set of upgrades, and one of the coolest features is the integration to Twillio and the ability to send text messages (SMS) directly from the ZUMO script.

Let’s go ahead and extend our previous ZUMO example (managing a list of sports team) with SMS messaging.

We all have different devices at home, right? So I had this idea, why not make a small Web API driven Windows service to sit on my main machine, to which I can send documents, which in turn will send them to the printer and print out. Sounds great doesn’t it?

Since Web API self host can be without any problems hosted as Windows Service, the whole application is really simple to put together. Let’s do that.

There’s been a lot of community buzz about Typescript recently – and rightfully so – as it solves a lot of Javascript’s issues, and despite being in its infancy, shows a tremendous amount of potential already.

One of the features (or side effects, depending on how you look at it) of Typescript, is that your are required to compile your code, to produce JS output. Sure, it is possible to dynamically compile Typescript in the browser (using its JS compiler), but that requires you to reference Typescript.js which is roughly 250 kB, and might be a tough pill to swallow.

However, using the ASP.NET Swiss army knife called Web API, and an approach we already disuussed on this blog before, let me show you how you can quite smoothly leverage on Web API pipeline to dynamically compile your Typescript code into Javascript at runtime.

More after the jump.

This is part two of the series - if you haven’t read part one check it out before proceeding.

Last time we did some cool stuff with using C# script files to instantiate a working Web API server - by executing them with RCSI and C# interactive window.

In part two, let’s use Roslyn to build our own scripting application (custom C# console), which will act as an input window for the user; user will be able type C# code that’s supposed to be executed and run it (something that services such as Compilify offer). We will expose Web API assemblies in that context, allowing the user to type in the code required for the Web API server to be run.

More after the jump.

If you follow me on Twitter you probably already know that recently I’ve been playing around with Roslyn. If you don’t know about Roslyn, in very short, you can think of it as “compiler as a service”.

There is a whole plethora of stuff that Roslyn allows us to do, one of the coolest being the scripting API - enabling us to use C# as a script language (think i.e. Perl or Python). So I had this idea, why not script a fully functional web server through Web API self host?

More after the jump.

There are a couple of things to consider when dealing with large file uploads and ASP.NET Web API. First of all, there are typical issues related to hosting within IIS context, and the limitations imposed on the service by default by the ASP.NET framework.

Secondly, there is the usual problem of having to deal with out of memory issues when allowing external parties or users to upload buffered large files. As a consequence, streamed uploads or downloads can greatly improve the scalability of the solutions by eliminating the need for large memory overheads on buffers.

Let’s have a look at how to tackle these issues.

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.