This project is read-only.

Extensibility point suggestion within IHttpActionSelector interface

Topics: ASP.NET Web API
Oct 4, 2014 at 8:56 PM

I've a situation where I need to select the given action within the controller based on the type of the authenticated user.

This can be done 2 way in my opinion:
  • Either by providing a Controller selector, and have 1 class with the same actions for all user types. I've tried this but I ran into some webapi internal errors, and I did not dig it down to the root cause, since the other way was much simpler to me, to have all the methods in 1 controller class, then select just between them.
  • So the second solution was to have a single class but with ambigous routes (same route for the same business action), then select between them.
I had to list a lot of sources just to get ApiControllerActionSelector class into my own codebase (more then 2000 LoC), since there was no extensibility point to filter between the ambigous ActionDescriptors.

The extensibility point can be called from the default case of the switch inside ActionSelectorCacheItem.SelectAction method.

If that method returns an ActionDescriptor from the passed in list of ambigous ActionDescriptors, then it can be returned, if not, the same behavior can be stay in effect what we've now.

I think that something similar would be great for Controller Selection too.

Too much internal stuff around these areas within the code.

What do you think of such feature?
Oct 7, 2014 at 7:56 AM

In general we do not want to keep extending the action selector and the controller selector because we find that they cause more trouble than good.

You should really try not to customize the framework and instead use it to get the results that you want.
For example: I'd suggest using attribute routing with constraints, Or even simpler, just have an if statement in your action.

Aside -
We do already have a similar extensibility point to what you are describing in vNext, but honestly it's a last resort kind of solution. You are taking pretty big responsibility by modifying the framework behaviors, and our recommendation at the moment is do it as a must only.

As we move forward to the next version of the framework, we will have a few additional ways to deal with this issue (still without touching the action selector, and there will be no more controller selector).
  1. You will be able to write a dynamic constraint (temporary name - ala MVC 5 ActionSelectorAttribute)
  2. You will be able to customize what actions look like to the framework without dropping attributes on them.
The gist is that the framework behavior is and should be constant, the inputs could vary (though they really shouldn't if they don't have to).

Here is a blog on the issue -

Hope this helps.