Solución:
HTTP es un protocolo basado en TCP / IP. Entonces, cuando usa REST, ya está usando TCP para la comunicación. Pero si desea utilizar REST sobre un socket TCP puro, sin HTTP, entonces no, esto no tiene sentido porque REST se basa en verbos y encabezados HTTP. Esas nociones existen solo en el protocolo HTTP.
REST es un estilo arquitectónico (o un conjunto de restricciones). Da la casualidad de que HTTP puede coincidir con todas esas restricciones fácilmente. Y además de eso, una gran cantidad de infraestructura HTTP / 1.1 ya la soporta: servidores, proxies, cachés, bibliotecas cliente, analizadores, etc. Algo como esto:
¿Se pueden construir sistemas desde cero en RESTful y no depender de HTTP? Seguro. Viniendo de la fuente autorizada sobre el tema, el propio Roy Fielding:
Una API REST no debería depender de ningún protocolo de comunicación único.
Si lees el artículo o, de hecho, la disertación de Roy, te darás cuenta de que si intentas seguir todas las restricciones, terminarás con algo que se ve y se comporta de manera muy similar al HTTP moderno, aunque probablemente carecería de la mayor parte del soporte de infraestructura que HTTP tiene. De ahí la pregunta: ¿Vale la pena?
Además, si echa un vistazo a la mayoría de los servicios RESTful, rara vez son servicios REST completos. Por eso se denominan a sí mismos “servicios RESTful” y no “servicios REST”. Por cierto, la API de este sitio se acerca mucho a una implementación REST completa.