Does WCF NetTcp binding increase coupling?

Question

Currently we have created web API's using either SOAP or a more plain HTTP REST-like approach. At the same time there are multiple ways to let server and clients more or less evolve independently, which I think is a big advantage.

One of the major downsides is that there is some overhead involved in using HTTP. We are planning to increase the use of service APIs to expose data instead of applications to access the databases directly. We are worried that using HTTP will involve too much overhead and this will increase latency. Of course we could make use of caching, but that would also increase complexity.

One the suggestions is to use the WCF NetTcp binding, which is supposed to be much more performant. I am worried that if we would choose this technology we might loose the benefits of REST: the ability to evolve server and clients independenty. I think we will increase performance at the cost of tight coupling.

My question is as follows: using WCP NetTcp binding, is it still possible to evolve your APIs without having to update all clients? In other words: what degree of coupling can we expect between client and server when using this binding?

Answer 1

We are worried that using HTTP will involve too much overhead and this will increase latency One the suggestions is to use the WCF NetTcp binding, which is supposed to be much more performant

Who says that? Ask them to show you benchmarks as I don't see how TCP would improve the performance that much. Sure it uses a binary protocol, but the business logic in the server is probably the bottleneck and not the actual transfer.

HTTP is much better since there are already a lot of ready to use infrastructure that will help you scale later of if required (like load balancing, cache proxies etc)

Answer 2

I believe the binding that you want to use depends on the who are the consumers of the service. If you already have clients using REST HTTP Client or SOAP with a specific binding, switching over to Net TCP will still need service update to all the clients already using the service. Since HTTP already has lot of infrastructure available, I don't see much value in switching the bindings.