I was recently asked how to filter out local requests in Web API. Indeed, one of the more useful things that developers got used to work with in traditional ASP.NET (and the System.Web.dll) was the ability to quickly check if a given request is a local one or not - by simply calling the IsLocal boolean property on HttpRequest.

This has been omitted from HttpRequestMessage in the new HTTP object model, around which Web API is built, but Web API still keeps track of that information under the hood, so you can easily write a simple extension method to bring back the old familiar syntax.

More after the jump.

If you follow Web API on User Voice or track Web API issues on Codeplex, you’d probably know that one of the most popular requested features of Web API is to allow the developers to combine HTTP verb action dispatching (default one), with action-name based dispatching in a single controller.

The rationale is very obvious, and I’m pretty sure there is not a single Web API developer in the world, who hasn’t run into this problem - by not being allowed to combine these, whenever you want to create a nested resource, you need to add a new controller and manually register a funky nested route to facilitate it.

Let’s create a custom action selector to solve this.

One of the great features of the Microsoft ASP.NET WebAPI OData package (which you can grab as prerelease from Nuget, and which will soon, in next release cycle, become part of Web API core) is a little dynamic proxy object called Delta.

It allows you to perform ridiculously easy mapping of properties between the model obtained from the database and the model passed by the client - thus facilitating all kinds of update scenarios your application may encounter.

Unfortunately, it will not work for you - unless you commit to ODataMediaTypeFormatter and all the extravaganza related to OData. What if you want to use the traditional API formatters, but still leverage on the power of Delta?

Let’s have a look at how you can perform really smooth full (PUT) and partial (PATCH) updates of your resources in Web API.

I recently stumbled across a [comparison of JSON serialization libraries][1]. which shows that ServiceStack.Text by far outperforms any of the competitors. Indeed, the folks down at [ServiceStack][2] have been building a lot of great stuff for the past few (4?) years to facilitate their framework.
ServiceStack.Text is available [on Nuget][3] and can be used outside of ServiceStack, within any .NET project, so why not use it with Web API, replacing the default serializer, JSON.NET?

Let’s do that.

A lot of people think that ASP.NET Web API is basically a fancy framework for building APIs - which couldn’t be further from the truth. Web API is mainly about the new .NET HTTP programming model it brings to the table - embracing HTTP to perform a whole magnitude of web related tasks; and APIs are just a small portion of that. Hopefully if you follow this blog, you have seen examples of that already, as we often wander in the unkown areas of ASP.NET Web API, beyond building “traditional” APIs.

Today, let’s go back to the HTTP programming model and use Web API to asynchronously stream videos.

More after the jump.

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.