HEAD HTTP verb is defined in RFC 2616 as “identical to GET except that the server MUST NOT return a message-body in the response.” As such you can think of it as a twin brother of GET.

There are a lot of use cases for HEAD: pinging without the overhead of transferring data, or simply requesting information about the size of a resource (which can be used to provide download progress bar), just to name a few.

Unfortunately, out of the box, ASP.NET Web API doesn’t provide a mechanism of supporting HEAD or coupling GET & HEAD.

We can work around that.

I recently blogged about a technique of integrating SignalR with ASP.NET Web API through the use of action filters. A few people have asked, whether this approach (and SignalR now being part of Microsoft’s ASP.NET product group after all) works with other frameworks. And the answer is absolutely yes. Let’s have a look at implementing this for ServiceStack. Adding ServiceStack 🔗You should probably have a look at the original article first, since the SignalR part of it will be identical.

Protocol Buffers are a super efficient and very flexible way of serializing structured data. Developed at Google, provide the developers lightspeed serialization and deserialization capabilities.

There a handful of .NET implementations, the most popular one, called protobuf-net, created by Marc Gravell from StackExchange. On top of that library, WebApiContrib project has a Web API Protocol Buffers formatter ready for you to plug in.

More after the jump.

There have been quite a few examples circulating on the web on how one would use SignalR together with Web API. It all started after Brad Wilson had a great example on calling SignalR from API controllers at NDC Oslo 2012.

Even on this blog we looked at calling SignalR from Web API ITraceWriter to provide realtime tracing capabilities.

How about, to avoid any controller-level noise, messaging the connected SignalR subscribers from ActionFilters? While this approach might not be applicable in all scenarios, when it is, I think it could provide a nice layer of separation.

More after the jump.

A friend of mine was recently complaining about how Web API controller centric approach doesn’t really make sense, and that he prefers feature-oriented endpoints. While - in all honesty - I am not sure what he means by that, it got me thinking. Maybe, if we didn’t have to suffix Web API controllers “Controller”, that would make him happy?

More after the jump.

In my humble opinion, Microsoft Roslyn is one of the most exciting things on the .NET stack. One of the many (MANY) things you can do easily with Roslyn, is write your own development-time code analysis tools.

We have talked about Roslyn scripting capabilities on this blog before (twice actually). Let’s look at code analysis today and see how we could built tools that could help Web API developers build nice clean HTTP services.

More after the jump.

Azure Mobile Services is definitely one of the coolest technologies in the Azure family. One of the issues however, has been that it only has client libraries for Windows 8, iOS and Android, making it a bit more difficult for developers targeting other platforms (also web browsers!) to take advantage of its capabilities.

A while ago, I blogged about how to work around that - by using ZUMO REST API. However, you still didn’t have access to one of the nicest features of ZUMO for mobile devices - and that is push notifications. That changed recently, when ZUMO announced a partnership with Pusher, to provide push notifications for virtually any client.

Additionally, the team recently released another cool feature - scheduled tasks (cron jobs). Let’s see how you can use it all together to quickly build a realtime service.

More after the jump.

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.