How do I manage the technical debate over WCF vs. Web API?

Question

I'm managing a team of like 15 developers now, and we are stuck at a point on choosing the technology, where the team is broken into two completely opposite teams, debating over usage of WCF vs. Web API.

Team A which supports usage of Web API, brings forward these reasons:

Web API is just the modern way of writing services (Wikipedia)
WCF is an overhead for HTTP. It's a solution for TCP, and Net Pipes, and other protocols
WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes
SOAP is not as readable and handy as JSON
SOAP is an overhead for network compared to JSON (transport over HTTP)
No method overloading

Team B which supports the usage of WCF, says:

WCF supports multiple protocols (via configuration)
WCF supports distributed transactions
Many good examples and success stories exist for WCF (while Web API is still young)
Duplex is excellent for two-way communication

This debate is continuing, and I don't know what to do now. Personally, I think that we should use a tool only for its right place of usage. In other words, we'd better use Web API, if we want to expose a service over HTTP, but use WCF when it comes to TCP and Duplex.

By searching the Internet, we can't get to a solid result. Many posts exist for supporting WCF, but on the contrary we also find people complaint about it. I know that the nature of this question might sound arguable, but we need some good hints to decide. We're stuck at a point where choosing a technology by chance might make us regret it later. We want to choose with open eyes.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

What should I do now? How do I manage this debate in a constructive way?

Don't forget, Web API doesn't make it easy for consumers to generate a service client like a SOAP WSDL does. If you're only ever going to have .NET clients it's not a big deal because they can share the contract objects you implement, but other language clients will need to manually create their client objects if you don't use SOAP. — Jimmy Hoffa, Aug 05 '13 at 14:09
also remember that WCF can do json pretty decently in most cases as well — Bill, Aug 05 '13 at 14:47
I think it depends on what you're trying to achieve/build and what will be connecting to it. If you're clients WILL ALWAYS be connecting using HTTP then WebAPI would be the way to go (SignalR can manage the Duplex side of things). If you need to connect some clients using other protocols TCP/Sockets then go for WCF. However bare in mind that MOST clients can and will happily connect and consume from an HTTP stack anyway so you could always implement a WebAPI service and "bolt on" a WCF pass-through type service which internally maps the incoming non-HTTP requests to WebAPI endpoints. — bUKaneer, Aug 05 '13 at 16:06
*"3. WCF models are not POCO"* that is simply incorrect. You do not have to use any attributes since .NET 3.5 SP1. — Allon Guralnek, Aug 08 '13 at 18:58
This question appears to be off-topic because it is about managing a debate amongst coworkers, not about software development. — GrandmasterB, Aug 08 '13 at 19:37
Wikipedia defines "the modern way of writing services"? Not sure how that is useful. — Frank Hileman, Aug 09 '13 at 18:37
"*SOAP is not as readable and handy as JSON*": You are about to design a service API. Why on earth should readability be important? It's only important, because this way the developer will get a handy debugging aid, but surely not for e.g. performance reaons. — JensG, Nov 05 '13 at 20:30
@JensG, of course JSON is much more lighter than SOAP. Just count the characters. — Saeed Neamati, Nov 06 '13 at 04:38
@SaeedNeamati: I never doubted that. But that's not the point here. A binary protocol for example tends to produce even shorter messages than JSON, but is less readable. But **human readability does not matter vis-a-vis designing an machine-readable Service API** where your main concerns are performance and traffic. It could be a nice-to-have side effect, but not more. So that whole argument is nonsense too. — JensG, Nov 06 '13 at 19:10
"WCF supports multiple protocols (via configuration); WCF supports distributed transactions" Well, are they proposing a design that will take advantage of those? — user16764, Feb 21 '14 at 17:39
Take a look at this post: http://blog.rees.biz/2013/09/restweb-api-and-wcf.html You should consider this: "The WCF Web HTTP programming model will continue to be supported, but all future innovations around REST and HTTP services will be focused on ASP.NET Web API." — Akira Yamamoto, Oct 29 '14 at 19:43
"WCF supports distributed transactions" <-- Thats actually a con, not a pro. Distributed transactions is a trap and using them is generally a sign of a system that hasnt been properly designed. — wasatz, May 13 '20 at 07:47

score 38 · Accepted Answer · answered Aug 05 '13 at 15:10

38

When both sides have good arguments and the opinions on the issue are too strong to come to a consensus, you as a manager need to make a decision and end the debate. Otherwise it will just turn in circles and fortify the positions of all participants even more. The longer you wait, the harder will it be for the "losing" side to admit defeat and work productively with the outcome.

Write down all the arguments, value their importance for the project, and then make your decision. When you can't, flip a coin. Your project can likely be completed succesfully with either technology, and wasting valuable time with unnecessary debates will just cost unnecessary money.

answered Aug 05 '13 at 15:10

Philipp

23,166
6
61
67

3

Dear @Philipp, thanks for the **flip the coin** suggestion. But as I said, I don't want to regret this **chance** decision. While I believe that agility matters, I also believe that good decisions matter too. – Saeed Neamati Aug 05 '13 at 15:15
5

@SaeedNeamati: If, after gathering and weighing all the information, no technology has a clear advantage, then flipping a coin is the most honest way of deciding. No matter the outcome of the toss, it is a good decision, because you weighed all information. – Bart van Ingen Schenau Aug 05 '13 at 15:31
9

@SaeedNeamati: I completely agree with "flip a coin". Right now you are in a clear [analysis paralysis](http://en.wikipedia.org/wiki/Analysis_paralysis) (your exact words are on that wiki page), which IMO is more dangerous than picking a decision that may not be "the best". If you have such a hard deciding, that means that even the other, less optimal decision isn't that bad. And as long as you architect your software in a modular way, you should be able to leave enough abstraction to take one technology out and put the other one in if needed, which is very unlikely in either case. – DXM Aug 05 '13 at 15:40
2

@SaeedNeamati In terms of technology, there's no such thing as "regret" this decision. You will always make mistakes. What's more important is to be able to detect mistakes asap, admit them openly, and change decision for the better. – Sleeper Smith Aug 06 '13 at 23:38
4

Other options: knuckle fight; wrestling match; person who shouts loudest wins. Surely these are better than flipping a coin? :) – Frank Hileman Aug 09 '13 at 18:35
With soap no one ever looks at the soap message especially with basic binding ... So its XML vs json ,.if you take out namespaces Namespace() and use custom default values xml is smaller in most cases and it compresses better. – user1496062 Dec 22 '15 at 01:41

score 13 · Answer 2 · edited Aug 05 '13 at 20:16

Assuming both sides are 100% correct in all of their arguments, which ones matter?

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

Do you care? Are you planing on doing something that requires POCO?

WCF supports distributed transactions

Again is this something you are going to use and need to build if you don't have it because you took the other path?

Basically get to the heart of which one:

Offers everything you need (If neither offer everything you need which makes you have to do the least amount of work).
Offers the least amount of junk you aren't going to use but have to put up with anyway.

Any argument put forth that isn't in the path of what you need to accomplish is irrelevant and should not factor in to your decision, with some wiggle room for considering future expansion.

WCF Data Service models are POCO, only requirement is an [name]ID field iirc. — Maslow, Oct 21 '13 at 16:51

MaxSC · Answer 3 · 2013-08-05T17:12:40.437

Put my two cents in.

As a manager, you should ask your teammates to keep in mind the Yagni principle. This will help to reduce the list of reasons brought forward by both Teams.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Rather than diving into distributed transaction, you should consider working with compensation instead.

Last thing to take into account is the learning curve. Depending on the deadline of your project, as a manager, you should be able to decide whether it's ok to start learning a new technology or not.

If you have plenty of time to waste, then go for some kind of Innovation Day where Team A and B would have a day to produce proof of concepts based on the same requirements.

By the way, to the guy that says "WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes", tell him that POCOs are generaly meant to be domain entities and that it's not a best practice to expose your domain object to any kind of clients, this is what DTO's are for.

+1 for not exposing domain objects in the fascade/external contract .Done this at least 10 times for the cheap wins and in 9 of them refactored due to the pain in having a fixed comms contract and managing a domain change. +1 for Distributed transactions , its a very evil thing .. — user1496062, Dec 22 '15 at 01:45

score 5 · Answer 4 · edited May 23 '17 at 11:33

What should I do now? How do I manage this debate in a constructive way?

First, keep subjectivity away. In your WebAPI team's arguments, I find "Web API is just the modern way"*, "WCF models are not POCO, because of those attributes" and "SOAP is not as readable and handy as JSON" pretty opinionated, if not plain wrong, and will not help make a decision.

So, what to do: decide what you want to do with your service(s), then choose a technique that accommodates that goal and its maintainability and extensibility with the least amount of pain. You can do this by simply researching whether any given aspect is supported by the framework to use.

Interesting reading material:

*: note you refer to Wikipedia for this, where the citation is: "Web 2.0 web applications have moved away from a service-oriented architecture (SOA) with SOAP-based web services towards more cohesive collections of RESTful web resources". That's an example of use for when your service is to be consumed from a webpage. This can also easily be done with WCF, using the WebHttpBinding. It does not say "Use WebAPI for this".

If this question stretches beyond the "how to manage the discussion": I would use WCF if the services are to be consumed by non-web-clients, because its metadata allows for astonishingly easy strongly-typed client generation.

Not only that. "*XYZ is just the modern way*" is a NULL-Argument, which usually reads as "*I have no real arguments, but it's my personal favourite of the season.*" — JensG, Nov 05 '13 at 20:27

score 4 · Answer 5 · answered Aug 06 '13 at 23:52

Team management aside, you do not choose one over the other. You need to look at the purpose of each web service and use the appropriate technology for the specific part of the application. It's like banning store procedures when the team is using entity framework.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Then you write those 5~10% web services in WCF. If the service is to be referenced internally in other projects, there's no debate. The advantage of the ability to import WCF contract to create the client proxy is NOT open for discussion. It takes the whole integration, efficiency, and type safety to a whole new level.

You write what's to be used for public api(maybe) / Ajax requests in Asp.net web api.

If it's just page specific ajax call, you can just use Asp.Net MVC.

Don't choose, embrace them all. WCF and Asp.net web api serve different purposes. No one says you can't have apple and orange both in your fruit salad. Trying to pick one over the other and shoving it down every single scenario is just sheer laziness.

score 4 · Answer 6 · answered Aug 08 '13 at 19:36

Our team had a similar discussion a couple of months ago. The deciding factor for us came down to how we would create and implement each technology. Since we were already building an MVC application and were using Knockout.js for data binding, we were effectively using MVVM with the controllers just being an API for data.

This allowed us to categorize our use of the technologies with this project as follows:

Web API would be used as our API for knockout and Ajax calls, making them our commands for the MVVM pattern. Our business logic for the web application is wrapped up behind this layer through a number of classes and repositories and factories.
WCF is then used for our data store, exposing data from our database for not only this website, bit also for any other site or service that consumed the exposed data.

While this might not be a popular or hyper technical response, determining what you need first and how or if the technology will help is what helped my team decide which technology to use where.

how does your WCF layer handle Auth? – Maslow Aug 08 '13 at 19:40 — Maslow, Aug 08 '13 at 19:40

score 3 · Answer 7 · answered Aug 07 '13 at 06:16

In other words, we'd better use Web API, if we want to expose a service over HTTP, but use WCF when it comes to TCP and Duplex.

That would be the most reasonable approach. It's quite common to have both WCF and WebApi services in the same web application where both serve different purposes.

Just to correct few arguments:

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

In many cases WCF models work without datacontract/datamember attributes.

SOAP is not as readable and handy as JSON

It is not, true, but WCF web services usually carry plain XML rather than bloated SOAP. This definitely is readable.

One argument for WCF: if there is a WSDL available, there are tons of tools in almost all technologies that can create proxies out of the metadata. On the other hand, the JSON Schema is not yet all widely supported.

score 2 · Answer 8 · answered Aug 08 '13 at 19:22

Why not walk the line with WCF Data Services? nice OData/webapi style queries and usability with the powers of WCF, and the ability to return JSON just fine. Also Wcf isn't that bad if you have a nice automatic wcf hosting code like the following:

https://github.com/ImaginaryDevelopment/MvcOdata

I'd say they aren't far separated at all, except that when we went to use WebApi on the front end and WCF data services on the middle tier, the WebApi threw up on simple things like string contains or string matching odata operators.

svidgen · Answer 9 · 2015-08-14T16:48:33.647

A good architect delays technology decisions until they're absolutely necessary to make.

In other words, don't make the decision until a client needs to actually connect. You can build a fully tested service layer without actually putting a transport/commnication mechanism over it. 95%+ of the work can be done "beneath" the adapter, outside the framework.

Come time to expose those services to remote clients, you can pick the trendiest framework off the shelf and write thin wrappers over a versatile service layer.

Hell, if your "real" service layer is done well, you can even try several wrappers at a minimal expense.

That's the dogmatic answer, anyway. In practice, you may want to pick the simplest tool off the shelf to facilitate early and frequent integration tests -- but, still limit your dependence on it and treat it strictly as a simply thin communication layer over the real services.

If you take this approach, you'll probably find that you pick the simplest tool to use initially and no one will fuss, because the team knows they can implement a more sophisticated or trendy tool or framework later, if necessary, with minimal effort.

Admittedly, this answer is very late to the game -- but, I was really surprised to see none of the popular answers regurgitated the dogmatic "don't even make the final decision yet" answer ... — svidgen, Aug 14 '15 at 16:44

score 0 · Answer 10 · answered Nov 05 '13 at 14:12

Hence I'm facing the same choice now, I asked myself what is the subset of features from WCF our team is using at the moment. Do we use different protocols? No. Do we use transaction support? No (although we use custom eventual consistency mechanisms). Do we use duplex? No.

Why we would like to use Web API? Easier frontend integration (removes additional service layer existing now), SignalR for pushing reply to clients, caching for GETs.

May be, one could find other reasons :) As well, reasons to stay with WCF.

The OP isn't asking about WCF vs Web API, the OP is asking about how to manage the internal, technical debate his team is having. Your answer misses the broader part of the question. — , Nov 05 '13 at 15:29

score 0 · Answer 11 · answered Feb 21 '14 at 17:34

If I were in your position I would start by examining your teams abilities. If everyone on your team already knows WCF and only a small percentage know Web API then your decision is already made for you.

By all means if you have the time then invest it in learning and improving your knowledge base, but not at the expense of the business need and company productivity.

score 0 · Answer 12 · answered Aug 15 '15 at 06:42

I would ask what model of interaction do you need to support? Does your desired external interface more resemble RPC or REST? In my experience it's usually somewhere between but mostly one or the other.

Are you consuming your own services for other projects in .Net? This is probably the single most revealing question you can ask. WCF does have the advantage of being able to abstract your interfaces into a separate class library and be able to build and inject your client. As an extension to this, you can mount your WCF based project with both JSON and SOAP/WSDL endpoints, I've done it. WCF also offers better assurances against your defined interfaces.

That said, if you expect to have clients from other platforms XML in general, let alone SOAP has a measurable overhead beyond what simple JSON endpoints have. If you go the JSON/Web API route, then you will need to become much better at documenting how to interact with your endpoints and API.

In general, I would suggest writing a simple API document that states how you will submit data, and how you want a response for a single request object structure. Write your test case in the most universal way, and document it as such. I'd recommend a simple curl statement. Then have several of your members implement this using WCF and with Web API. Then see which wins.

Personally, despite having done some relatively large projects and implementations with WCF, I actually lean towards the simplest implementation which in my mind is actually straight WCF with using JSON results and some override behavior in the Global.asax.cs for dealing with error conditions. If an API's documentation includes curl statements, and you can exercise all of the functionality of your API with curl examples it becomes much easier for clients to be implemented in any language that supports web interfaces. This is really where WCF starts to fall down. Having a well defined API with agnostic documentation is better than having structures with automated tooling when dealing with foreign systems. Speaking as a consumer of those systems from other platforms.

One thing beyond that, is implement your client in two disparate languages. Do a client in C#, but also do one in Node.js or Python and see how well they actually fit. That exercise alone will help you shake out the loose ends in your API.

How do I manage the technical debate over WCF vs. Web API?

12 Answers12