I'm checking out Web API and I'm not sure how asp.net mvc and web api can or should work together.
I want to implement Backbone on the client side, but I'm not sure if I should implement an ApiController or a normal Controller on the server side?
The way I'm doing things (Getting current user / account information) is that a base ApiController will have some of the same functionality as a base Controller would, which would lead to a bit of duplicate functionality, but not sure what would be the other trade offs.
Or would you only create an ApiController for a public service that you want to provide and stick to Controllers for the web app?
This is almost exactly the situation I am in, except that I am using Knockout.js rather than Backbone. I have views for Create and Edit and within each view, a very complex Knockout.js UI which does loads of Ajaxing of JSON back and forth to the server.
Under MVC3 I was using numerous JsonResult methods within the same controller which rendered the views. I've been experimenting with the RC of MVC4 and was pondering whether to go down the "route" (ho ho) of using an API controller for the Ajax requests. I like the strongly typed HTTP classes and the fact that JSON.NET is more integrated, but at this stage, I have to say that the end result of having a separate API controller for my own internal use just didn't feel right. Like you, I found that I ended up with a lot of duplication around security, and the separation of what was related logic simply by content type made things more confusing rather than cleaner.
So at this point (although I have been known to be fickle) I plan to keep using standard MVC controllers for my current context, but I'll jump at a chance to use the shiny new Web API if I end up exposing a public API.
If you're planning an API, use the ApiController. If you're doing Web UI stuff, use the classic Controller. That's what both are made for.