RESTful HTTP services vs direct TCP or WebSockets for back-end communication

Question

Why are RESTful HTTP services so popular even in backend communications nowadays, except that it is a standard and simple?

I would never choose HTTP-REST for back-ends that require low latency and/or high throughput, mainly because:

1. HTTP uses a one-way request-response paradigm, that is not a full-duplex streaming.
2. HTTP implies packet-length and other information which is an overhead.

I can see RESTful web-services in many open-source projects, claiming that they are for low latency, high throughput. As an example, it is quite popular to create RESTful micro services, embed light-weight http-servers into server-side applications.

As an alternative I could use WebSockets (via HTTP upgrading of course) over TCP.

I am aware how HTTP works under the hood as well as a lower layer TCP. But please explain, except that HTTP-REST is a buzzword and simple that's why you should use one, any other advantages?

Answer 1

RESTful HTTP is a well established technology whereas WebSockets only became a W3C recommendation during summer 2014.

On one side, it takes some time until new technologies make their ways into products because people have to adopt to new technologies and very often you also do not want to rewrite your product just to have WebSockets.

On the other side, and more importantly, RESTful HTTP and WebSockets are completely different technologies. RESTful HTTP is stateless so you can build highly scalable applications. WebSockets on the other hands are bidirectional so both end, server and clients, can trigger communication. So at the end your decision should be based on the scenario. There have been cases in the past where RESTful HTTP was the perfect solution and so will it be still today. On the other hand scenarios that require real-time communication or server driven events will profit from WebSockets.

But the important thing: from now on you have a choice!