>OK - good points.
>
>But I don't think it's fair to say WebApi is a dead end any more than saying MVC is. Surely both are merged into vNext?
>
>The controller in this example looks very similar to current Web Api controllers: http://www.asp.net/vnext/overview/aspnet-vnext/create-a-web-api-with-mvc-6

Nope it's just modified MVC. The WebAPI model is completely dead. There are no HttpRequest/ResponseMessage objects, there's no OWIN/Katana pipeline - it's all different.

If you just used controller methods to return raw value results - yes you'll be able to do that in vNext with the mixed model (and as I said you can do that easily in MVC as well with a custom action filter).

My point is the WebAPI architecture - how the actual request flow and low level mechanics work is gone - it's not there in vNext. There will be a support shim that can help transition WebAPI code in vNext, but it'll be an extra layer added for backwards compatibility.

If you're building new stuff that you want to port to vNext, I'd recommend you stick with MVC today as that will be a much smoother transition than WebAPI.

+++ Rick ---

>
>BTW the link on this page to 'Creating ASP.NET MVC Negotiated Content Results' goes to the next item : http://west-wind.com/articles.aspx
>
>>Attribute routing works with MVC and has as long as it's been available inside of ASP.NET.
>>
>>FWIW, I get that WebAPI has cool features. I was an avid advocate - until Microsoft killed it. The thing is you can do anything you could do in WebAPI with MVC with only a little bit of tweaking. I had way before WebAPI came along and I've gone back to it in light of WebAPI being a dead end. I've always hated the fact that you ended up having both WebAPI and MVC in an app that shares both HTML and API views as most SPA apps do. Two similar models that duplicate functionality and do things slightly differently.
>>
>>But my main point is WebAPI is a dead end. It won't be developed any further as it's not in ASP.NET vNext.
>>
>>The new MVC includes the features of Web API and MVC merged into a single pipeline, and with a little bit of work for creating a few custom controllers and filters you can provide the same interface as you could with WebAPI using even the current version of MVC, without the overhead of spinning OWIN ontop of System.Web (ie. duplicated stacks). Especially for JSON based backends (which is pretty much all I ever build these days) MVC works just fine.
>>
>>With the extensions I use in the current MVC I get all of these features:
>>
>>* Using JSON.NET instead of JavaScript Serializer
>>* Content Negotiation
>>* Content Negotiation for Errors (ie. JSON/XML responses for errors)
>>* Using raw results instead of ActionResults (although I don't actually use that)
>>
>>I've written about all of these on my blog with small implementations for each.
>>
>>+++ Rick ---
>>
>>>Not convinced :-}
>>>
>>>I find the Web api pipeline easier to understand than the MVC model and just as extendable (at least, I've not found any problems)
>>>
>>>I like this representation of the web api model : http://www.asp.net/media/4071077/aspnet-web-api-poster.pdf
>>>Closest I could find for MVC is on a link here : https://www.simple-talk.com/dotnet/.net-framework/an-introduction-to-asp.net-mvc-extensibility/
>>>
>>>But the nicest benefit of Web api for me (which I mentioned before) is 'Attribute Routing' - before this was added Web api suffered from the same disadvantages as the MVC convention-based approach.
>>>
>>>Anyway - each to his own........
>>>
>>>>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 ---