One of the more annoying issues in the current version of ASP.NET Web API, is that it’s very difficult to override global/controller scoped filters at action level.
Perhaps you may have logging functionality or authorization filters, that you want to apply globally, and only exclude certain actions from participating in this process.
This problem is remedied in Web API vNext (version 5), and you can try that out with nightly builds.
Sometimes (or perhaps, quite often?) you only need to support JSON in your ASP.NET Web API. In these cases, the ability of Web API pipeline to facilitate various media types is of no value for you – and you probably do not care at all about content negotiation.
In such situations it is often suggested to remove other media type formatters and only leave JsonMediaTypeFormatter. In fact, the author of this blog has earned almost 20 StackOverflow points for this type of suggestion.
However, there is even better way to solve this problem, and you’ll love it if you are into micro-optimizations.
One of the common tasks, for logging or authorization purposes, is to obtain the IP address of the client accessing your Web API.
There are different ways to achieve this depending on whether you are web hosting (through HttpContext) or whether you are self hosting (through WCF’s RemoteEndpointMessageProperty).
To avoid the redundant code, we can unify those approaches under a single extension method, which you can use across all your projects.
Hopefully by now you have already heard about the sriptcs project, which allows you to write script based applications with C# and Nuget.
If not, have a look at the readme and the great introduction post by Scott Hanselman to get started.
Actually, just today, we have released v.0.4 of scriptcs! To celebrate that, let’s revisit one of our favorite topics – Azure Mobile Services – and how you can use it with scriptcs.
As you probably know, the ASP.NET team is publishing the latest ASP.NET Web API on a nightly MyGet feed, and you can grab them from there and play with the latest stuff without having to deal with all the hassle related to building from the source.
The same applies to Katana, a Microsoft generic Owin host, which also has its own MyGet nightly feed.
Let’s glimpse into the near future and have a look at putting the latest Katana bits to play with ASP.NET Web API and other frameworks.
Following the last article on parameter binding from URI, I received an interesting question – “what if I wanted to prevent binding parameters from query string and only allow binding from route values”? In other words, prevent passing values to actions via query strings and only look for them in the route itself (to avoid duplicate ways of reaching the same endpoint).
This is possible in Web API – let’s explore how you’d go about implementing it.
More after the jump.
Today, let’s kick off a series intended to look at different aspects of HTTP parameter binding in ASP.NET Web API. Why? Aside from the awesome series by Mike Stall, there isn’t really that much material on the web on this particular subject. And developers coming from MVC background, often get surprised by differences in the model binding mechanism between MVC and Web API.
In this first post, let’s have a brief overview of parameter binding in Web API and then specifically look at binding model from URI.
More after the jump.
Today I have published a new article over at my friends from Tech.pro. This time, we continue on the topic of SignalR & Knockout.js, and look at implementing a real-time collaborative route planner with the use of Google Maps API. Hopefully you’ll enjoy the article as much as I enjoyed writing it.
These libraries, really make a lot the development tasks feel like true magic!
As you usually, the source code is on GitHub.
Head over to tech.pro to read the tutorial!
Today I stumbled upon an interesting Stackoverflow question, where the user was asking how to go about self-hosting Web API in LinqPad.
The question has gone unanswered since December, and I’m guessing even the OP forgot about it. However, I’d like to elaborate a bit about the topic. You certainly can host Web API in LinqPad, provided you plug in a quick work around – and we actually did hit a similar issue with scriptcs.
ASP.NET Web API does a really good job at letting you control the amount of error details returned in the framework responses. And that is for both your own (“developer-generated”) exceptions, as well as the ones produced by the Web API itself.
However, this setting (IncludeErrorDetailPolicy) is global, and configured against the HttpConfiguration, making runtime manipulation of the error detail policy rather difficult.
However there is a trick you can use.
More after the jump.