Controller/RequestContext and ApiController/HttpControllerContext

Topics: ASP.NET MVC, ASP.NET Web API
May 11, 2012 at 1:08 PM

I am developing a hosted web component framework using MVC 4 and Web API.  I'm using Web API for the purely RESTful calls and the "normal" MVC plumbing for rendering HTML and dynamic JavaScript scripts.

I'm just doing a sanity check here to make sure I'm approaching things correctly.

I have created an MvcControllerBase derived from Controller and an ApiControllerBase derived from ApiController to contain all of my common stuff (which right now is authentication / session management - and session being only an authentication token, no other state).  I chose to create derived classes instead of action filters so that I could centralize all of the common stuff in one place.  90% if not all controllers will derive from one of these two classes, so it seemed more efficient to go this route.

As I am overriding Controller.Execute(RequestContext) and ApiController.ExecuteAsync(HttpControllerContext, CancellationToken), it's becoming clearer that the underlying framework is different for the two.

Since I'm laying the foundation for my framework going forward, I'm trying to get things "clean".  I realize that things are still very much changing in MVC 4 / Web API, and that "clean" today may not be "clean" tomorrow, but the "cleaner" I can keep it now, the less cleanup I'll have to do later :)

So after the long winded intro, my real question is:  In trying to create centralized code for request processing, such as authentication, I'm finding I need to support both RequestContext for MVC controllers using Razor to render views and HttpControllerContext for my RESTful API controllers.  Is this what I should expect currently or am I missing something?

As I'm writing this I realize that if when using ApiController I could hook into the View() rendering used by "normal" Controllers, I could use the ApiController for everything.  My "normal" controllers are actually called via AJAX/jQuery and then the resulting script executed in the browser or HTML injected into the page.  So being able to render Razor from an ApiController would allow me to unify my controllers.

But if it makes more sense to keep Razor-rendered calls in the "normal" Controller and my API's in the ApiController, then my original question stands: Do I need to deal with both RequestContext and HttpControllerContext in my common code or is there an underlying unified Request/Response interface I can use for both?  I'm guessing that since the ApiController abstracts the response with HttpResponseMessage that I have to support both.  From my experience so far, you can't set underlying response values before returning your HttpResponseMessage and have them "survive" through to the actual response sent back on the wire.

May 11, 2012 at 3:17 PM

 In trying to create centralized code for request processing, such as authentication, I'm finding I need to support both RequestContext for MVC controllers using Razor to render views and HttpControllerContext for my RESTful API controllers.  Is this what I should expect currently or am I missing something?

My personal view on this is that this parallel world between MVC and Web API (which is the source of most criticisms while community has generally praised the product) is mainly a consequence of the fact that Web API has been added to MVC without having a reference (or knowledge of it).

As Jon Galloway said on a recent podcast, had the team have HTTP knowledge they have now (as well as hindesight of the popularity of REST API now which they did not have then), they would have designed just a single pipeline serving data and rendered view alike.

I can only speculate that the future version of MVC/Web API will be presented as a single pipeline. In fact, this parallel world might have been a careful plan to unify them in the near future.

May 11, 2012 at 6:10 PM

In hindsight, I'd change how I've handled a good portion of my life, so I won't criticize the team for what they've learned in the process :)

From what it sounds then -- and this verifies what I observed -- I need to support the two methods for the time being.  Not a huge deal, and if my common code grows to the point where maintenance becomes an issue, I'll create an abstraction layer so that my common code will read/write headers and other request/response data the same way.

I am liking the Web API HttpRequestMessage, HttpResponseMessage path.  It would be cool to see things unify on that in the future.

May 11, 2012 at 11:18 PM

Yes, what you have felt is the main criticism I have heard. Yet I have a lot of respect for the team and I think this is going to be more promising than any managed high-level framework Microsoft has ever done.

Let's wait for the future of this as I feel they will merge.