Please, no "They solve 2 different problems" answers, it's the same HTTP request and response problem. Just because you have views/templates in MVC doesn't mean you have to use them. M_C is good enough for serving XML and JSON.
Please, no "It's what Microsoft says you should do" answers. If I thought that way I wouldn't be asking this question.
Apparently people did not like how I phrased my question, but the title is very clear. I'd like to learn what WebHttp can do that MVC can't, or what both can do but with WebHttp it's easier or more powerful.
I'm really looking for details, not a high level description of when to choose one over the other.
There is a lot more overhead in an MVC application. Since you don't really "need" Url-rewriting when serving other services (not SEO-sensitive), or don't need Google robots to understand what's important, you don't need that - and so the routing overhead is unnecessary.
The ASP.NET MVC assemblies needed for the core MVC functionality contains view-specific methods, causing them to be larger. If your only purpose is to serve JSON/XML there is no need for extension methods for creating textboxes, checkboxes etc.
It would also be an easier task to do unit tests for a WCF service, since you you don't need to bother with mock controllers, mock contexts etc.. (given JSON-response is the only thing you're providing)
So bottom line - it's unnecessary to use ASP.NET MVC for serving only JSON-data unless you want to provide the comsumer with some kind of GUI in combination with the JSON data.
One acronym comes to mind: KISS. :)
Still not a resolved issue I see. I'll try again...
If you want a fully fleged website with nice looking URLs and MVC based architecture, ASP.NET MVC is obviously the way to go. Now, I totally understand this is not what you're asking - and to be honest, your question is slightly vague, so I might not get it this time around either.
WebHTTP in .NET 4 is a slight simplification of the WCF services that were introduced back in .NET 3, and it follows the trends in web development today. WebHTTP has a really extensive support for customizing your URLs, controlling the response that would be tough - or basically just alot of work - to achieve with regular WCF and also in MVC for that matter.
Picture buying a pizzaslicer and a pair of scissors. You can cut pizza with both, but the slicer will undoubtably be more efficient. You can also cut paper with both, but the best result will be with the scissors.
You can achieve the same things with MVC and WebHTTP, but for instance creating a View is just alot more straight forward with MVC because that's part of its main function (it's actually in the abbreviation). Varying the responsetype from one single method, on the other hand, is a trivial task in WebHTTP whereas in MVC it requires more tinkering. The same goes for making a RESTful service. WebHTTP was made for stuff like that - MVC was not.
Bottom line - you can achieve pretty much the same things in both, but they are tailored for different needs.
If this wasn't the "right" answer either, perhaps you could provide some background for your question?
They have nothing to do with one another. WebHttp is for (as an example) creating ajax entry points for your web services. ASP.NET MVC is about the server-side delivery of HTML pages. And yes, I know you asked me not to give you this answer. But it is only because I believe you are missing something in your understanding of the question.
