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!
Update
I should say that I've now implemented 3 separate large REST services using MVC 2 & 3, and it's a joy to work with. I've written model binders to wrap around WCF's DataContractSerializer for XML and of course JSON support is just fine. I won't go back now.
WCF is a best fit for scenarios like message queues, duplex communication, end-to-end message security, one way messaging, distributed transactions, etc. WEB API is a best fit to create a resource-oriented services using HTTP/Restful and it works well with MVC-based applications.
Use WCF to create reliable, secure web services that are accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services.
WCF is used for developing SOAP-based services whereas Web API is used for both SOAP-based and RESTful services. WCF does not offer any support for MVC features whereas Web API supports MVC features. WCF supports HTTP, UDP, and custom transport protocol whereas Web API supports only HTTP protocol.
Yeah; you always could create a REST API with XML as response.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With