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?
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)