I've been looking into WebAPI and really like what I see.

Is there are reason why NOT to use WebAPI? If so, in what scenario?

I initially thought in a cross-platform SOA architecture, WebAPI might fall short, but the more articles I read, the more I realise that WebAPI might beat WCF in almost every realistic scenario. It looks like you can use WebAPI for android, ios etc. and not just for .Net; even performance shows WCF REST to be slowest. http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance

Is there still an "obivous" reason where WCF is better?

  • see the following URL I think it could help you about webAPI: stackoverflow.com/questions/10346342/… OR programmers.stackexchange.com/questions/207239/… – MLSC Dec 2 '13 at 11:30
  • WCF and WebAPI are two similar (web services)but different (SOAP vs REST) things that both have their place. WCF is capable of interacting with non-.NET clients as well. – Tim Dec 2 '13 at 16:53
  • 1
    You should not be consuming WCF services from a browser-based client, except in some extreme and poorly planned scenario where you should have instead adopted some entirely different technology like WebSockets. If you're debating consuming WCF services from a browser-based client, just don't. Use WebAPI instead, use something else for back-end server-to-server comms. – Shaun Wilson Sep 15 '14 at 1:04

Whenever you control the both the consumer and provider endpoints (for example back-end service-to-service communication) you should use WCF (or Sockets) for capabilities and performance. Hosting the service via WCF and then sharing binary contracts means 100% guaranteed matching, compiler-checked and type-safe (de)serialization between client and server.

If you also have full CI you all but eliminate the risk of releasing binaries with mismatched contracts. Web API serialization is more forgiving, and thus verification and testing is more involved (client can send data server does not expect, server can send data client does not expect.) WCF also supports contract versioning and extended data, this allows intermediary services that only know V1 contract can still accept and forward to a V2 or later message while preserving all data for services which understand V2 or later contracts!)

WebAPI is mainly for implementing HTTP-based services with minimal frustration, as such, WebAPI relies heavily on the asp.net HTTP Web Stack to function (whereas WCF and its underpinning's do not, matter of factly, some WebAPI features rely directly on WCF.. for example, exposing OData feeds via WebAPI.)

Similar to Web API endpoints, WCF endpoints can be configured to provide access via HTTP as necessary (among other protocols and technologies such as Secure Named Pipes, MSMQ, UDP, TCP, etc.) WCF is also extensible, and out of the box it provides transport implementations for duplex, bidirectional and reliable messaging, it provides both Transport-level and Message-level authentication using Tokens, Certificates, basic Authentication Credentials and more. There is additional support for service discovery, subscription, broadcasting, etc. (Admittedly, WebAPI provides some overlap, but not with the same level of control.)

Not only does WCF support all this, it is highly configurable allowing you to mix and match between MOST of the available transport, formatting/serialization, security, instancing, lifetime and other service settings through configuration files and code.

Moved two of your middle tiers together into same machine now? Switch to a named pipe. Swapping a server from .net to PHP? No problem, change binding config from using net.tcp to use soap. Where WebAPI stops, WCF continues.

However, as with any technology, WCF only shines as well as your developer's understanding of networking and infrastructure. Put in the hands of the mediocre or unwilling and you will get a complete mess that fails to perform. WebAPI is a little bit more fool proof, even beginner programmers can put it to use within minutes, and generally succeed at their task doing so.


  • 1
    Most of the time this is true, but given a large enough scale you will also want to couple more tightly than WCF (currently) allows, sometimes you just need to write raw sockets code to handle the load being thrown at you. Typically you still develop these 'cushy' front-end web servers that expose APIs to your web developers, but for all that hardcore back-end work you should be using WCF or something lower level (0MQ, protobuf-net + tcp sockets, something tiny and purpose-built, etc) – Shaun Wilson Sep 15 '14 at 1:00

Your Answer

