Javascript client - which is likely to be better serverside? WCF or MVC3 controller with restful messages?

Question

I'm looking to write a server side service, which will be accessed from a Javascript/HTML5 client.

The client will likely be sending a bunch of restful messages over HTTPS.

All other things being equal, which is better designed to support this kind of scheme on the serverside - WCF or MVC3 (ie., a controller with only restful messages, no real view or model)?

Answer 1

If the use case is pretty simple and you've already got to support a MVC site then I think MVC is a pretty good choice. I'd also generally agree that standard WCF is perhaps a bit too much ceremony and boilerplate and difficult to IoC in a sane and rational manner.

All that said, you might want to check out the WCF Web API. It is pretty simple to implement at first, plays well with your existing MVC site while also having some pretty powerful message handling facilities. Your typical MVC controllers start to fall down a bit -- or at least the level of complexity increases dramatically -- when you get into stuff like ETags, cache hinting and such. The Web API bridges that gap nicely and it is definitely worth checking out.

Answer 2

I recently came up against the same choice: I'm writing a rich web application with MVC3 for server-side and needed to host restful services for those pages to hit.

I ended up going with using MVC3, and so far it has been working very well. With WCF it feels like there is a lot of boilerplate and configuration you have to do just to get started, and very little benefit if you never plan on exposing the services any way other than REST.

All it takes is a controller that returns a JsonResult. The syntax is also really neat. The Json method takes any plane old object and serializes it to json, which makes it really easy to use Linq to project your data to anonymous types that give a very clear indication of what you are returning:

return Json(new 
{ tasks = _TaskList.Where(t => t.Active)
    .Select(new {name = t.Name, status = t.Status, owner_id = t.Owner.Id}) 
});

Now, you also mention having no model. But your controller must be executing some sort of business logic, correct? You want your controller to still be relatively thin, it should be delagating the real work to the "model", whether this is another class, a library another service, whatever.

Answer 3

Do you anticipate needing to support other clients down the road? For instance SOAP, message queue, TCP/IP? WCF has a strong interoperability story here.

Personally, I like working with Data Contracts and Service Contracts, and love the flexibility of being able to do one way asynchronous architecture when I want durability or scalability one day and use RESTlike HTTP the next day while still maintaining compatibility with SOAP clients.