They're not really. WebAPI is built on top of MVC, but uses some different base classes (which is annoying as hell at times). [Edit] Plus what vyrotek said [/Edit]
I think it has more to do with getting uptake among the WCF crowd than anything else. IF MS doesn't specifically call it out the folks that had bought into the kool-aid to use WCF for all services probably would never see it. As it is, only 50% of them will see it.
The MS stack has a LOT of 80% developers who are buried in the bowels of some organization happily doing the same thing they've been doing since they first learned .NET.
Heck, I had a call from an organization the other day looking for a senior developer, but they had to have intimate knowledge of a perticular third parties UI control library, because that was what they were using when they wrote the original application in VB6. Couldn't convince them that they probably don't need the 3rd party controls for an HTML app, not could I convince them that any senior developer worth hiring would be able to understand and use said library in a matter of hours if they were truly needed.
Over the last three years I've come to understand that it's I'm not that I'm awesome, it's that most developers are just bad at their jobs (present company probably excluded).
It's a common misconception that Web API is built on or tied to MVC. It's not though. You can use it in a WebForms site just as easily as in an MVC site. You can even self-host Web API outside of IIS entirely.
Also, Web API isn't intended to replace WCF. The "connected systems" people have a whole different set of needs than people building simple web-facing APIs. I don't think we should expect to see WCF or "Add Service Reference" going away anytime soon.
I had totally forgotten about that, although I have seen WebForms used in an MVC site as well.
I did NOT intend to imply that it was a replacement for WCF. I meant to imply that it is a replacement for the WCF REST Starter Kit, and if MS didn't make a huge deal out of it, a lot of people that had gotten used to using WCF for web services would never see it.
Web API is actually built on a completely different HTTP pipeline than ASP.NET products. When it moved to the ASP.NET team, there were a number of changes made to make it feel more natural to ASP.NET devs. Hence the slight variations when you dig under the covers. The question we need to ask ourselves, is why would the ASP.NET team agree to continue to support a completely new HTTP pipeline.
Because unlike ASP.NET it can be self-hosted [1]. It wouldn't surprise me if ASP.NET was moved onto System.Web.Http in the future. Because ever since ASP.NET MVC they have been trying to hide the old System.Web under the new System.Web.Abstractions to support unit testing.
Implementation details. To the person using the products, they are nearly identical, with one being for web sites and one being for APIs. I see no reason why these should be separate. Please explain.
ASP.NET MVC is approx. 3 years old product and to support the features of the current ASP.NET Web API in an elegant way, lots of breaking changes would occur in ASP.NET MVC. This is just one of the reasons. You might also see this one as another impl. detail but it is the brutal truth.
It's pretty impressive to see people who have no idea about the technology they are talking about. ASP.NET Web API doesn't force REST at all! Go learn what that FX does in the first place before leaving comments like this.
The WebAPI project has an interesting history. It was owned originally by the WCF team and then was taken over by the ASP team. A lot of the supporting code for it comes from a new Namespace too. That makes some things slightly annoying when hosting an API in your MVC application.
Comments
I can't figure out why MVC and WebAPI are separate products.
They're not really. WebAPI is built on top of MVC, but uses some different base classes (which is annoying as hell at times). [Edit] Plus what vyrotek said [/Edit]
I think it has more to do with getting uptake among the WCF crowd than anything else. IF MS doesn't specifically call it out the folks that had bought into the kool-aid to use WCF for all services probably would never see it. As it is, only 50% of them will see it.
The MS stack has a LOT of 80% developers who are buried in the bowels of some organization happily doing the same thing they've been doing since they first learned .NET.
Heck, I had a call from an organization the other day looking for a senior developer, but they had to have intimate knowledge of a perticular third parties UI control library, because that was what they were using when they wrote the original application in VB6. Couldn't convince them that they probably don't need the 3rd party controls for an HTML app, not could I convince them that any senior developer worth hiring would be able to understand and use said library in a matter of hours if they were truly needed.
Over the last three years I've come to understand that it's I'm not that I'm awesome, it's that most developers are just bad at their jobs (present company probably excluded).
It's a common misconception that Web API is built on or tied to MVC. It's not though. You can use it in a WebForms site just as easily as in an MVC site. You can even self-host Web API outside of IIS entirely.
Also, Web API isn't intended to replace WCF. The "connected systems" people have a whole different set of needs than people building simple web-facing APIs. I don't think we should expect to see WCF or "Add Service Reference" going away anytime soon.
I had totally forgotten about that, although I have seen WebForms used in an MVC site as well.
I did NOT intend to imply that it was a replacement for WCF. I meant to imply that it is a replacement for the WCF REST Starter Kit, and if MS didn't make a huge deal out of it, a lot of people that had gotten used to using WCF for web services would never see it.
Web API is actually built on a completely different HTTP pipeline than ASP.NET products. When it moved to the ASP.NET team, there were a number of changes made to make it feel more natural to ASP.NET devs. Hence the slight variations when you dig under the covers. The question we need to ask ourselves, is why would the ASP.NET team agree to continue to support a completely new HTTP pipeline.
Because unlike ASP.NET it can be self-hosted [1]. It wouldn't surprise me if ASP.NET was moved onto System.Web.Http in the future. Because ever since ASP.NET MVC they have been trying to hide the old System.Web under the new System.Web.Abstractions to support unit testing.
1. http://www.asp.net/web-api/overview/hosting-aspnet-web-api/s...
Implementation details. To the person using the products, they are nearly identical, with one being for web sites and one being for APIs. I see no reason why these should be separate. Please explain.
ASP.NET MVC is approx. 3 years old product and to support the features of the current ASP.NET Web API in an elegant way, lots of breaking changes would occur in ASP.NET MVC. This is just one of the reasons. You might also see this one as another impl. detail but it is the brutal truth.
Gleen Block has a 20 minutes long video on this topic if you need more info: http://www.tugberkugurlu.com/archive/why-do-i-need-asp-net-w...
What features? The difference between MVC and Web API, to those using it, is that Web API uses restful routing and MVC does not. That is all.
It's pretty impressive to see people who have no idea about the technology they are talking about. ASP.NET Web API doesn't force REST at all! Go learn what that FX does in the first place before leaving comments like this.
The WebAPI project has an interesting history. It was owned originally by the WCF team and then was taken over by the ASP team. A lot of the supporting code for it comes from a new Namespace too. That makes some things slightly annoying when hosting an API in your MVC application.