How do I manage the technical debate over WCF vs. Web API?
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
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?
المحلول
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.
نصائح أخرى
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
