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.
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 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.
I have published an article at Tech.pro today, about building a real-time shopping cart with some of our favorite technologies – ASP.NET Web API, SignalR and Knockout.js (or, as Brad would say, with the “Webstack of Love”).
Click here to head over there and read the article!
Some time ago I posted a mini-series of posts about using Roslyn to script Web API, and that has gotten some great response. In that original post, I mentioned & used, without going into too much details, a very useful “compiler as a service” feature Roslyn offers.
Recently, Glenn Block started a very exciting project called scriptcs (which now Justin Rusbtach and I happen to be a part of too) to provide a seamless/node.js-esque scripting experience for C# and in that project we indeed leverage on Roslyn heavily – to do some behind the scenes tricks to hide the compilation aspect from the user, so that it really resembles pure script execution.