CODEWITHSUNDEEP
c#asp.netwcfasp.net-web-api
Rob
Rob

Reputation: 3574

Difference summary WCF and Web API

I'm looking for the difference summary between ASP.NET MVC Web API and WCF Service.

I've seen this question What is the difference between Asp.Net Web API and WCF Service? and this question WCF vs ASP.NET Web API too, but they don't summarize what I can achieve with the one, what I cannot achieve with the other.

So in short: What can I do with WCF what I cannot do with ASP.NET Web API and visa versa?

Upvotes: 2

Views: 913

Answers (2)

Raja Nadar
Raja Nadar

Reputation: 9489

this list is by no means exhaustive.

Things WCF does that you cannot do (with ease) using Web API.

  1. Supports SOAP based XML format.
  2. Supports strongly typed data contracts.
  3. Supports a single point of metadata information exchange using WSDL etc.
  4. Supports varied bindings like TCP, Named Pipes, MSMQ, even UDP etc.
  5. Supports varied hosting options like console apps, WAS, IIS, Windows Services.
  6. Supports one way messaging, duplex, message queues out of the box.
  7. Supports multiple authentication schemes like Windows, Forms, Certificates etc.

Things Web API does that you cannot do (with ease) using WCF.

  1. Supports the full features of HTTP. (Uri based access, Http Requests/Response, Http Caching etc.) To do this in WCF you need to additional work to configure it as REST service etc.
  2. Is Lightweight with minimal configuration.
  3. Supports the Routing, Controller/Action MVC paradigm, Model Binding etc.

Basically Web API is an easy way to do RESTful services over Http without knowing much about Web services.

To do the same in WCF, you need to do additional work in terms of httpBindings, UriTemplates, Verbs etc. And that means, understanding WCF first. And then using WCF to implement a RESTFul service over http, which is what Web Api provides out of the box.

Upvotes: 6

deostroll
deostroll

Reputation: 11975

This is not a summary per se. Its a sort of practical guide I hope.

For me it ultimately boils down to how simple I want my front-end application code to look like, and also something to do with how to achieve maximum productivity.

Traditional WCF over http is SOAP based messaging protocol. You add a service reference in your project, and Visual Studio takes care of generating the proxy classes. And you work with the instance of the proxy classes. So when you are writing your front-end code, you have intellisense to help you. Don't be fooled. This is just the IDE making life simpler for you. Underneath its pretty complicated. But my productivity is boosted to a degree. I don't have to write proxy classes. Hence, this is what I'd opt for a c# based front-end.

Alternatively, if I had to deal with a Webapi endpoint, I do not have the luxury of any IDE generated proxy classes. Therefore I'd have write code for everything. Typically I use the HttpClient classes to talk to my web api end points. Hypothetically, I could write a proxy classes to talk to web api. But it isn't as simple as in your wcf case where they were auto-generated for you.

On another line or reasoning, if my front-end was JavaScript, then my only best bet is have the web service hosted over web api, rather than wcf. If I were to talk to wcf endpoints from Js, that would be a PITN.

So it ultimately rests on your product plan, design, project schedules, etc software development plan. All the best.

Upvotes: 3

Related Questions