I actually use custom filters and custom serializers for this so my 'API' MVC controllers behave more like APIs. I do prefer returning ActionResults just like in WebAPI I return HttpResponseMessage rather than raw results. It's just a cleaner way to work and gives you much more control if you use custom filters. There's also much better control over output handling in MVC and the whole programming model for extensibility is much cleaner, than the nasty low level API in WebAPI. If you stick to basics yes WebAPI appears to be easier but any serious work you do you will end up extending both WebAPI and MVC.

So no I don't agree that WebAPI is cleaner especially since I can duplicate that same 'clean' object based interface with very little support code in MVC. WebAPI's main feature that separates it from what you can accomplish with MVC is that the stack is async from the bottom up which means it scales a bit better (although overall performance is actually lower) and allows you to self-host.

+++ Rick ---

>>>>>Thanks for responding, but I think I will take Rick's advice and start over small. angular and web api with empty mvc project.
>>>>
>>>>One more thing: I would probably use MVC instead of Web API. Going forward in vNext there will be no WebAPI, just a combined version of MVC that handles both HTML views and API access. MVC works just fine for APIs and with a little customization you can build the same functionality like WebAPI with MVC as well (ie content negotiation, and raw result values).
>>>
>>>Hmm. Haven't really used it but the new 'unified' controller in MVC6 seems to take more from the old API controller than the MVC controller. And the MVC controller is pretty kludgy for data. I'd argue that knowing the current Web Api controller (using attribute routing, etc) would make migrating to MVC6 easier...
>>
>>
>>No not really. YOu still have action results with MVC, but ActionResults are really more like an HttpResponseMessage. You can't return raw objects unless you build a custom filter that manages the result explicitly (which you can do with MVC 6 but couldn't do with MVC 5 due to that lack of type info).
>>
>>IAC, curious why you say it's kludgy for data? Granted there are improvements that can be made (and I've done some of that for my API interfaces as described here: http://weblog.west-wind.com/posts/2014/May/20/Creating-ASPNET-MVC-Negotiated-Content-Results ), but overall using MVC is pretty painless for services IMHO.
>
>OK, 'kludgy' may not be the right word but I'm sure you'll agree that the web api is superior for data. When using the MVC controller you have to serialize every response yourself (and the MVC Json serializer isn't ideal). Web api handles that for you and the serializer/s to be used can simply be set in the configuration.
>Add in attribute routing (which makes it far simpler to build a more conformant RESTful interface) and the fact that web api has no dependency on the asp.net pipeline and, to me, it seems a no-brainer choice.
>
>OTOH, for SPA applications (which tend to be what you want with angular) the MVC controller brings little to the table - nearly all views can be static html; razor becomes almost irrelevant. And, if you do need dynamic html, then, just as it's possible to do data with MVC, you can return html from the web api.
>
>My 2c :=}
>
>>The biggest issue with the current version of MVC is that it's not async optimized, but MVC 6 will be all async.
>>
>>+++ Rick ---
>>
>>
>>
>>
>>>
>>>
>>>>+++ Rick ---