views:

291

answers:

3

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.

+2  A: 

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.

Kirk Woll
are you saying asp.net mvc cannot serve JSON ?
Max Toro
No, not saying that. So if the question is why would you use WebHttp over ASP.NET MVC for the purposes of serving JSON, then it's a matter of taste, or more likely, which platform you are already writing in. But ASP.NET MVC represents far, far more than that.
Kirk Woll
@Kirk Woll: I know and understand everything you said, so you are really not helping in answering my question.
Max Toro
@Max - why the combative attitude? Ignore the answers you don't like.
DaveE
+7  A: 

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

Yngve B. Nilsen
Although, the question "In what ways is WCF WebHttp better than ASP.NET MVC?" could be answered in a different way:WCF WebHttp is NOT better than ASP.NET MVC since ASP.NET MVC has URL-rewriting, routing, the posibility to return different content-types for one single method (HTML, Json, XML, RSS/Atom, Binary etc, etc);)
Yngve B. Nilsen
@Yngvebn: Your answer is more about "MVC having too much unneeded features" than "WebHttp really shines at X". Also, never said that my only purpose is to serve JSON/XML.
Max Toro
Well in that case, let's break it all the way down in terms of HTTP Request/Response.There's no difference. GET is sent to the WebServer, and whatever you have running there handles the request and responds with whatever you tell it to respond with.I simply don't understand where you're going with your question :)
Yngve B. Nilsen
My comment to your comment: WCF with `Stream` or `Message` and as return type can do also return any content types in one single method (also images excel tables and so on).
Oleg
Alright, to put it like this: If you have never worked with any of the two before (ASP.NET MVC and WebHTTP), and you need a simple REST-server, go for WebHTTP to avoid having to learn stuff that is not needed. If you already know ASP.NET MVC, go ahead. As of right now, there aren't much difference between what they can or cannot do. WebHTTP is fairly new, so I would guess in a year or two we'll see alot of improvements on it. So you might argue that WebHTTP will develop in a more serverlike fashion, whereas MVC will develop in an even more Web frontend framework.
Yngve B. Nilsen
And to add to that - Maybe we're seeing a separation of concerns here, that ASP.NET MVC could merge with WebHTTP, so that WebHTTP will provide the controllerlogic and the current ASP.NET MVC will implement this instead of the current controllers. (just a thought) :)
Yngve B. Nilsen
+1  A: 

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?

Yngve B. Nilsen
@Yngvebn: You are saying creating RESTful services is easier with WebHttp, but you are not saying why.
Max Toro
Well, I'm no WebHTTP-expert, but from what I've seen and read there are alot more out of the box that enables you to easily achieve "RESTfulness".Have a look at this blog-series, as it covers a lot of the mechanisms in WebHTTP:http://blogs.msdn.com/b/endpoint/archive/2010/01/07/getting-started-with-wcf-webhttp-services-in-net-4.aspx
Yngve B. Nilsen