RESTful HTTP Services vs. Direct TCP or WebSockets for Internal Communication
Why is RESTful HTTP services so popular even in backend communications nowadays, except it's standard and simple?
I would never choose HTTP-REST for back-ends that require low latency and / or high throughput, mainly because:
- HTTP uses a one-way request-response paradigm, which is not full-duplex streaming.
- HTTP implies packet length and other information that is overhead.
I can see RESTful web services in many open source projects claiming they are designed for low latency and high throughput. As an example, it is quite popular to create RESTful microservices, embed lightweight HTTP servers into server applications.
Alternatively, I could use WebSockets (via HTTP refresh of course) over TCP.
I know how HTTP works under the hood as well as lower layer TCP. But please explain, other than that HTTP-REST is a buzzword and simple, why should you use it, any other benefits?
source to share
RESTful HTTP is a well-established technology, whereas WebSockets became only a W3C recommendation in the summer of 2014.
On the one hand, it takes a while until new technologies turn into products because people have to embrace new technologies, and very often you also don't want to rewrite your product just by having WebSockets.
On the other hand, and more importantly, RESTful HTTP and WebSockets are completely different technologies. RESTful HTTP is stateless, so you can build scalable applications. WebSockets in other hands are bidirectional so that both ends, the server and the clients, can initiate communication. So at the end, your decision should be script-based. There used to be cases where RESTful HTTP was the ideal solution, and it will be so today. On the other hand, scenarios that require real-time or server-driven events will profit from WebSockets.
But the main thing: from now on you have a choice!
source to share