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
As I am overriding
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.