WCF vs Web API

Analogy categoryAnalogies

Two Different Philosophies

WCF was built to be protocol-agnostic: the same service contract can be exposed over HTTP, TCP, named pipes, or MSMQ simply by adding a new endpoint and binding, and it has deep support for WS-* standards like WS-Security and WS-AtomicTransaction for enterprise SOAP interop. ASP.NET Web API, by contrast, was designed HTTP-first and resource-oriented from the start, built around HttpRequestMessage and HttpResponseMessage, plain JSON by default, and straightforward content negotiation — it never tried to be protocol-agnostic because REST over HTTP was the entire point.

🏏

Cricket analogy: WCF's protocol flexibility is like a broadcaster who can deliver the same match feed over satellite, cable, or radio depending on the market, while Web API is like a streaming app built purely for one platform — it does that one thing exceptionally well without the overhead of supporting three delivery mechanisms.

Contracts, Bindings and Messages vs Controllers and Actions

A WCF service is defined declaratively through ServiceContract, OperationContract, and DataContract attributes, and the wire format is heavily shaped by the binding chosen in configuration — switching from basicHttpBinding to wsHttpBinding changes security, reliability, and even parts of the message envelope without touching the contract code. Web API instead uses ApiController classes with public action methods, routed via attribute routing or convention-based routes, and model binding pulls parameters straight from JSON, form data, or the query string with far less ceremony — there's no equivalent of svcutil-generated proxies or a WSDL contract to keep in sync.

🏏

Cricket analogy: Changing a WCF binding without touching the contract is like a stadium switching from red-ball to pink-ball day-night conditions while the actual rules of the game stay identical — the 'ball' (binding) changes, not the laws (contract); Web API's routing is more like a straightforward T20 format with simple, fixed overs and no such configuration layer.

When to Choose Which

WCF remains the right tool when you need distributed transactions (WS-AtomicTransaction), reliable messaging with guaranteed ordering, duplex callbacks, or a non-HTTP transport such as named pipes or TCP for high-throughput intranet services, and especially when interoperating with legacy SOAP clients that expect a WSDL contract. Web API — or its modern successor, ASP.NET Core Web API and Minimal APIs — is the better choice for public REST APIs consumed by mobile apps and single-page applications, where JSON content negotiation, simpler testing without generated client proxies, and lower ceremony matter more than transactional guarantees.

🏏

Cricket analogy: Choosing WCF for transactional guarantees is like insisting on the full DRS review system for a World Cup final where every decision must be verifiably correct, whereas Web API is like a casual backyard match where a quick, informal call is good enough and speed matters more than ceremony.

Migration Considerations

WCF can be made to look RESTful by adding webHttpBinding along with WebGet and WebInvoke attributes, but this is a bolt-on adaptation of a SOAP-oriented framework rather than a native REST design, and it lacks the model binding and middleware pipeline conveniences of a purpose-built HTTP framework. Teams migrating off classic WCF today generally go one of two directions: adopt CoreWCF, the community-maintained, .NET-compatible port that still provides SOAP/TCP/duplex features for services that genuinely need them, or rewrite the service as ASP.NET Core controllers or Minimal APIs when plain HTTP/JSON is sufficient — note that the original System.ServiceModel server-side stack was never ported to run natively on modern .NET without CoreWCF.

🏏

Cricket analogy: Bolting REST support onto WCF is like retrofitting a Test match ground with floodlights for a one-off day-night game — it works, but the venue was fundamentally designed for a different format, unlike a stadium built from scratch for T20.

csharp

// WCF: contract-first, binding-driven
[ServiceContract]
public interface IProductService
{
    [OperationContract]
    Product GetProduct(int id);
}

// Web API: HTTP-first, attribute-routed controller
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id}")]
    public ActionResult<Product> GetProduct(int id)
    {
        var product = _repository.Find(id);
        return product is null ? NotFound() : Ok(product);
    }
}

The classic System.ServiceModel server-side WCF stack does not run natively on modern .NET (5+); it was Windows-only .NET Framework technology. CoreWCF is the community/Microsoft-backed port that fills this gap for teams that must keep TCP, MSMQ, or duplex features while moving to modern .NET, rather than rewriting everything as a Web API.

WCF is protocol-agnostic (HTTP, TCP, named pipes, MSMQ); Web API is HTTP-first and REST-oriented by design.
WCF's wire format is driven by binding configuration; Web API relies on straightforward attribute or convention routing.
WCF supports WS-* standards like WS-Security and WS-AtomicTransaction for enterprise SOAP interop.
Web API offers simpler JSON content negotiation and testing without generated client proxies.
Choose WCF for distributed transactions, reliable messaging, duplex, or non-HTTP transports.
Choose Web API/ASP.NET Core for public REST APIs consumed by mobile and SPA clients.
CoreWCF is the modern .NET path for teams that still need WCF's transport features beyond plain HTTP/JSON.