views:

190

answers:

2

I spent a long time learning how to customise WCF from the point of view of adding authentication etc over a RESTful service; I built some custom service hosts, then added the ability to use an IOC container to actually create the service instance etc etc.

We have iPhone/iPad apps plus some other gadgety-type things (technical term!) that now use these (XML on the i-platform, JSON for browser-based) and I am very pleased with the performance and the ease with which we can add new operations etc.

I learnt all the foibles of the DataContract serializers (and now use them in isolated cases to read/write objects outside of WCF) and after that steep learning curve, but now that we have them I'm very happy with them all.

Now we have a series of new Web projects for which I jumped at the chance of using MVC - and have been suitably impressed with that; the model binding, in particular, really kicks arse.

I'm now looking at similar RESTful apis for these web projects (they will all be similar sites but different branding and minor changes in business logic depending on custom need). Originally, I expected that all this work on WCF would stand us in good stead - but MVC has its own development path for RESTful XML/JSON and I'm now caught between the two.

If you're writing an MVC site would you ever use WCF to implement its REST API?

I'll throw out one argument for using WCF - that, properly written, it can be isolated to run as a windows service without the need for a Web Server. However, that seems like a desperate case!

+2  A: 

I've never used WCF, but I am currently using MVC2 to implement a REST API.

For the most part it's well suited, but there are some gaps, and it's involved a bit of a learning curve. I've needed to use MVCContrib for better XML support. I've used MVC futures to support sending a JSON object to an action method (see: http://haacked.com/archive/2010/04/15/sending-json-to-an-asp-net-mvc-action-method-argument.aspx). I also needed to take the source for this and alter it so it could support XML.

I've heard there are some REST frameworks that sit on top of .NET MVC, but I've not had a chance to try them out.

If you're familiar with WCF and it worked well last time, then I would be tempted to stick with what you know.

Richard
Yes, it's the gaps in MVCs support that bother me slightly; I didn't find any gaps as such in WCF, just strange behaviour. But being able to integrate the API with the same state and object model as the MVC portion of the site would be a real bonus! Thanks for the links.
Andras Zoltan
Answer because of the links. And I think that you and Darrel are both suggesting MVC if I can - and so I will. Thanks to you both!
Andras Zoltan
+2  A: 

I've used WCF to do REST for quite a while and my recommendation would be to use MVC. If you only want to deal with XML and Json and if your URI space is relatively simple then you could probably could get by with WCF. However, once you step out of the basic stuff then you need to be very familiar with WCF to work around its default behaviour.

Darrel Miller
I would certainly agree that a good knowledge of WCF is required to get the best out of the REST experience. One thing in particular I don't like (but loved until I came across MVC) is the static routing - with URI template strings as attributes: the Route Table is just a much better solution.
Andras Zoltan
@Andras As far as I know they both use the same routing mechanism under the covers. The only difference is the way they fill the table. Over time there have been some versioning differences that have caused different behaviour, but they both use System.Web.Routing.
Darrel Miller
@Darrel - yes, sorry, you're right; and in my opinion MVC just gets it right - but then the two systems were designed to solve different problems. I am a huge fan of WCF (not initially though), and am just a bit nervous about saying goodbye to it for this purpose I think! How sad!
Andras Zoltan