title: RESTful HTTP services vs direct TCP or WebSockets for back-end communication
body: <p>Why are RESTful HTTP services so popular even in backend communications nowadays, except that it is a standard and simple?</p>
  
  <p>I would never choose HTTP-REST for back-ends that require low latency and/or high throughput, mainly because:</p>
  
  <ol>
  <li>HTTP uses a one-way request-response paradigm, that is not a full-duplex streaming.</li>
  <li>HTTP implies packet-length and other information which is an overhead.</li>
  </ol>
  
  <p>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. </p>
  
  <p>As an alternative I could use WebSockets (via HTTP upgrading of course) over TCP.</p>
  
  <p>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?</p>