Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

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

Team B which supports the usage of WCF, says:

  1. WCF supports multiple protocols (via configuration)
  2. WCF supports distributed transactions
  3. Many good examples and success stories exist for WCF (while Web API is still young)
  4. 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?

share|improve this question
8  
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 5 '13 at 14:09
7  
also remember that WCF can do json pretty decently in most cases as well –  Bill Aug 5 '13 at 14:47
3  
"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 8 '13 at 18:58
4  
This question appears to be off-topic because it is about managing a debate amongst coworkers, not about software development. –  GrandmasterB Aug 8 '13 at 19:37
3  
Wikipedia defines "the modern way of writing services"? Not sure how that is useful. –  Frank Hileman Aug 9 '13 at 18:37

10 Answers 10

up vote 28 down vote accepted

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.

share|improve this answer
2  
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 5 '13 at 15:15
3  
@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 5 '13 at 15:31
6  
@SaeedNeamati: I completely agree with "flip a coin". Right now you are in a clear 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 5 '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 6 '13 at 23:38
2  
Other options: knuckle fight; wrestling match; person who shouts loudest wins. Surely these are better than flipping a coin? :) –  Frank Hileman Aug 9 '13 at 18:35

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.

share|improve this answer
    
WCF Data Service models are POCO, only requirement is an [name]ID field iirc. –  Maslow Oct 21 '13 at 16:51

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.

share|improve this answer
1  
+1 for YAGNI. Just what I was thinking. :) –  winkbrace Aug 9 '13 at 20:45

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.

share|improve this answer
1  
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 5 '13 at 20:27

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.

share|improve this answer

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.

share|improve this answer
    
how does your WCF layer handle Auth? –  Maslow Aug 8 '13 at 19:40

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
2  
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. –  GlenH7 Nov 5 '13 at 15:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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