I’ll be holding two ASP.NET Web API presentations in Toronto this month - if you happen to be in the area, it would be an excellent chance for me to meet you, and dive into ASP.NET Web API together. I’ll be covering a magnitude of topics - benefits of Web API, how it fits into the existing .NET landscape, how it differs from existing .NET Web technologies, consuming Web API from different clients, hosting in WPF applications, in Windows services, cross system HTTP communication, content negotiation, in-memory-hosting and many more.

One of the often repeated, and frankly, somewhat unfair, arguments against using .NET based technologies is that by doing so, you handcuff yourself to all kinds of various Microsoft tools and products.

If you choose to use ASP.NET Web API, by no means you are tied to IIS. Of course, one of the options is to self host it (and run the web service using the hardened WCF core), but if you want a true web host flexibility and independence, you can very easily host Web API using OWIN and Katana.

More after the jump.

One of the topics we like to come back to on this blog is Azure Mobile Services (ZUMO) - and rightfully so, because that’s a terrific service, capable of smoothly fueling your application’s backend in a hassle-free and scalable manner.

One thing you might have noticed about ZUMO though, is that pretty much all the online tutorials and materials related to it will show you how to work with it from scratch. One of the unknown facts about it, is that, with some slight modifications, you can actually plug in your existing SQL Server (or rather SQL Azure) database (provided you have earlier migrated it to Windows Azure of course), and serve it for your application utilizing the power of Azure Mobile Services.

Let’s a have a look at how you’d configure that.

On this blog, I’ve been focusing pretty much exclusively on ASP.NET Web API, but today let’s step outside .NET, and explore how you could host RESTful HTTP services directly from the native unmanaged C++ code - and I hope, this is going to be a very interesting journey, especially as C++ is so much more efficient than any managed language.

If you haven’t done C++ before, or haven’t done any in years, don’t dread, modern C++ is quite different than what you might be used to of have heard of. Microsoft DevLabs and Niklas Gustafsson provide a terrific experimental library called [Casablanca][1], which is a C++ SDK aimed at creating modern HTTP services in native code.

More after the jump.

Web API help page, available for your Web API via the Nuget package or built into the Web API template if you used the ASP.NET Fall Preview installer, is an extremely useful tool for documenting your API. That is, both for the external users that will consume the API, but also for your own development team, especially if the API is part of a larger internal ecosystem of applications and you need an automated, quick and easy reference for everyone to be able to look at.

Recently, I have been asked how you could automate the exposure of some additional information about the API, such as whether an action requires authorization or what are the potential response status codes.

And sure enough, it is very easy to do.

More after the jump.

The latest ASP.NET Fall Update, released recently, introduced the Web API tracing package into the Web API core. It is the default implementation of ITraceWriter, built around the System.Diagnostics, allowing you to easily trace what’s going on inside your API and output that into the debugger’s console.

On this very blog, we discussed a similar approach a couple of months ago already, by building an NLog powered trace writer for your Web API.

Today, let’s take all this a step further, and build something much more exciting - a realtime Web API trace, powered by SignalR.

Regardless of what types of applications you are building with Web API, sooner or later you will run into a situation where you need to scope certain dependencies to the lifetime of a web request.

Examples of these types of in request scope dependencies could be loggers, unit of work implementations, NHibernate session, RavenDB session, Mindscape Lightspeed UnitOfWork or many other. Fortunately, this is very easy to do with Web API and an IoC container.

More after the jump.

First the disclaimer. Yes, there are a lot of problems with using session in your ASP.NET applications. Moreover, by default, HTTP (and by extension, REST) is stateless - and as a result each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP.

So if you are designing a proper API, if you are a REST purist, or if you are Darrel Miller, you definitely do not want to continue reading this article. But if not, and you find yourself in a scenario requiring session - perhaps you are using Web API to facilitate your JS or MVC application, and you want to sync the state of Web API with the state of MVC easily, or you simply want a quick and easy way to persist state on the server side - this article is for you.

More after the jump.

This evening, Microsoft has released a Fall 2012 Update to ASP.NET. The release brings a whole set of goodies for ASP.NET developers, including SignalR (now officially part of ASP.NET), C# FB app project template, Windows Azure Authentication and more. Jon Galloway has the updates very nicely summarized here.

Of course, as you’d expect, there are plenty of updates regarding Web API. Let’s have a look at them.

More after the jump.

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.