He does know about WebAPI.
They both have differences, and are equally valid choices. Aside from anything else, I give Nancy time because I'd love to see more open source independent development on the .NET platform.
Its routing is rubbish - waiting for V2 for fixed routing (AttributeRouting support so its not hidden away)
Its terrible to extend.
Its slower than Nancy.
Its hard to test out of the box.
Guess what, your website is an API, it just happens to return text/html instead of some other format you specify. If you use MVC and WebAPI, you're doing it wrong.
Also...
http://weblogs.asp.net/shijuvarghese/archive/2013/07/30/writ...
vs
http://www.marcusoft.net/2013/01/NancyTesting3.html
Sums up WebAPI for me.
SpringMVC + JAX-RS1/2
RoR + Sinatra
A web-app using some framework + NodeJS for API
There's nothing wrong with that as you may want to have different models or different configurations (throttling or whatnot).
Using MVC-based framework for your API endpoint is overkill.
WCF's only benefit is TCP bindings. If you're doing any HTTP stuff, stay clear of WCF.
Your issues with it might have more to do with you.
Odd that the two single replies I got are a couple of bulldogs desperately shooting any alternative to this submission down.
Configuration is a black art: it involves configuring the various WCF interfaces/components in XML. Because of the poor documentation and bugs this can be quite a lot of work. It was quite obviously architected to be used with a configuration UI - it's similar to XAML and IIS in that respect - only Microsoft never bothered making the investment the way they did for IIS + XAML.
It's also buggy - XML parsing in particular is broken - and the default serializers are horribly slow.
It's extremely extensible, but extension requires considerable work. A lot of the base classes are either sealed or internal (or both), which just exasperate this. Without either the source, the tests, proper documentation or the ability to extend existing implementations it turns a job which should take an engineer an hour into a job that will take them 3 months.
So basically, Microsoft have done done everything to make using WCF in anything but the most basic scenarios hard and expensive.
As others have said, if you're doing anything over HTTP then you're better off using either Web API or better yet ServiceStack. I have good experience with the latter.
I've implemented and used WCF in very large financial systems, under enormous loads pushing absolutely massive amounts of data around. These are very complex systems I am talking about, and WCF was used in many capacities, one of which was as a HTTP Restful service layer (and given that we also used it through queueing, and over TCP, it added a consistency to the stack).
It certainly wasn't perfect (the configuration happens to be a particular point of irritation), but it wasn't a pain-point at all. It just was a non-issue and did the job, and was no engineering challenge whatsoever.
But, I suppose, it was "basic" in that we looked to WCF as a service front-door, and didn't actually see any need to alter it much, in the same way that we don't modify the kernel of the Linux instances that we work on or the source code of the nginx variants we use. We have a different domain that is where we add value, and building (or extending) a service handler like that would have been a gigantic waste of time.
Which, I suspect, it is for most people who do so. People have this intrinsic desire to seemingly make their own tasks more difficult for often ill-conceived or illusory goals.
Trying to do a phased replacement of existing J2EE SOAP webservices without the ability to change the clients (meaning that you need wire-level compatible) and you'll see just how hard WCF is to extend.
The fact that it IS possible to do that kind of integration is a testament to just how powerful the framework is. It's just a shame that Microsoft didn't spend an extra 5% effort on the documentation (or just open sourced it).
I should add that we're currently using WCF as an integral part of our system as despite the drawbacks being able to support TCP (and MSMQ etc) and everything else in one framework is worth the extra complexity. Plus we have a lot of organizational knowledge of WCF now.
I used to be like you, think WCF was the bee's knees.
WCF promote poor service design, in an untestable manner, has no real support for DI, has terrible configuration, unhelpful exceptions, faults, message size limitations that cause headaches, horrifically slow. The only benefit to WCF is TCP endpoints. End of story.
;)
Um...okay. That says enough. End of story.
I'm glad MSFT is moving away from that.
WCF is fine until you need to extend it. Nancy, MVC, Web Api are much easier to extend.
Plus WCF needs all sorts configuration stupidity which alternatives just don't have.