In this question about using WCF and/or WebAPI, there is this quote:

I was asking myself the same question until I found this WCF and ASP.NET Web API comparison page on MSDN (with my own emphasis below):

Use WCF to create reliable, secure web services that 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. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.

Paraphrased: "The support for REST in WebAPI is more complete and future improvements will be in WebAPI"

Question: How is WebAPI more "complete" and "featurefull"? What is incomplete about WCF? What's been added to WebAPI?

And conversely, with regards to REST, is there anything in WCF that isn't in WebAPI?

  • 2
    WPF was created during the SOAP era. If you're still doing SOAP or something more exotic, WCF might be a good choice. But if you're doing something more modern like JSON services... Commented Sep 3, 2017 at 17:43
  • @RobertHarvey This is new development - but I've done WCF before and just hadn't thought of WebAPI until I did some more reading. I'm just wondering what is actually in WebAPI that isn't in WCF. HTTP and JSON input/output work in WCF just as well as I assume it would in WCF. How can you be "more complete" than that?
    – WernerCD
    Commented Sep 3, 2017 at 23:37
  • 1
    Honestly I've never used WCF, but I've been told that it is unnecessarily complicated for what it does. It was created at a time when Microsoft (and everyone else) was over-engineering everything. So far, that's been enough to keep me away from WCF. Commented Sep 4, 2017 at 1:02
  • @RobertHarvey True in some ways. However, WCF was conceived at a time when SOAP was king and people had begun to hate .NET Remoting. SOAP was designed for enterprise scenarios and even between different organisations. REST originally was just between JS in a webpage and a web server. Nowadays of course we are seeing REST as "API"s between organisations replacing SOAP particularly where all the bells of whistles of WCF/SOAP is not a requirement.
    – Deleted
    Commented Feb 1, 2018 at 5:50

1 Answer 1


WCF can be pretty complicated if you let it but is pretty easy if you need basic SOAP and that holds true even if you need a few frills and more exotic transport, authentication or protocol options. It's also good because you get the interface described (if you want) via WSDL. You won't get that with WebAPI but that's a REST vs SOAP thing.

REST/Web API is also easy enough but, in my opinion at least it's actually harder than WCF in a few ways. There's a lot of method annotations, mark up, magic text values interpreted to methods, use of reflection etc. that makes it a pain to follow if you change names and stuff. There's also no WSDL equivalent so you have to somehow already know the methods and structures.

Horses for courses. Personally I use REST from browser to DMZ website AJAX then WCF for website UI to the services within the LAN.

Browser<---->REST<----->Website<---->WCF<------->ServiceLayer<---->DB, other things.

If I had to pick one and one only it would be REST simply because it fits the browser side better. I don't though, so I use WCF for the back-end because it gives added simplicity and type safety. That may be a function of my limited knowledge and not generally true.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.