>>>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.

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 ---