¿En qué se diferencia GRPC de REST?

(3)

Estoy leyendo esta explicación de GRPC y este diagrama es de interés:

¿Cómo funciona la capa de transporte? Si está en la red ... ¿por qué se llama RPC? Más importante aún, ¿en qué se diferencia esto de REST que implementa una API para la capa de servicio (la clase en el cliente que tiene métodos que hacen una solicitud http)?

La capa de transporte funciona utilizando HTTP / 2 sobre TCP / IP. Permite conexiones de menor latencia (más rápidas) que pueden aprovechar una única conexión del cliente al servidor (lo que hace un uso más eficiente de la conexión y puede resultar en un uso más eficiente de los recursos del servidor).

HTTP / 2 también admite conectividad bidireccional y conectividad asincrónica. Por lo tanto, es posible que el servidor se comunique de manera eficiente con el cliente para enviar mensajes (respuesta / notificaciones asíncronas, etc.)

Si bien, tanto REST como gRPC pueden generar stubs de cliente / servidor (usando algo como swagger para REST), REST tiene un conjunto limitado de llamadas (o verbos) de ''funciones'' primarias:

mientras que gRPC puede definir cualquier tipo de llamadas a funciones, incluyendo síncrono / asíncrono, unidireccional / bidireccional (flujos), etc.

Usando gRPC, el cliente realiza una llamada a un método local. Para el programador, parece que está haciendo una llamada local, pero la capa subyacente (el código auxiliar del cliente generado automáticamente) envía la llamada al servidor. Para el servidor, parece que su método se llamó localmente.

gRPC se encarga de todas las tuberías subyacentes y simplifica el paradigma de programación. Sin embargo, para algunos puristas REST dedicados, esto puede parecer una complicación excesiva. YMMV

La mayor ventaja de gRPC sobre REST es su soporte de HTTP / 2 sobre el abuelo HTTP 1.1. Entonces, la mayor ventaja de HTTP / 2 sobre HTTP 1.1 es que ''HTTP / 2 permite al servidor "enviar" contenido'' ...

REST no requiere JSON o HTTP / 1.1

Puede crear trivialmente un servicio RESTful que envíe mensajes protobuf (o lo que sea) a través de HTTP / 2

Puede crear servicios RESTful que envíen JSON a través de HTTP / 2

Puede crear servicios RESTful que envíen mensajes protobuf a través de HTTP / 1.1

Los servicios RESTful no son un "hack" sobre HTTP / xx, son servicios que siguen los principios arquitectónicos fundamentales que han hecho que cualquier versión de HTTP sea exitosa (como la capacidad de almacenamiento en caché de las solicitudes GET y la capacidad de repetición de las solicitudes PUT).

gRPC, SOAP, et. Todos se parecen más a los hacks: los hacks en la parte superior de HTTP para hacer un túnel de los servicios de estilo RPC a través de HTTP, para enrutar las restricciones de firewall y middlebox. Eso no es necesariamente algo malo. A veces es posible que desee un servicio de estilo RPC en lugar de uno REST, y tenemos que vivir en un mundo donde los middleboxes son difíciles de reemplazar.

Si no tiene tiempo para leer la definición real de REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Siempre está el TLDR; versión en wikipedia:

https://en.wikipedia.org/wiki/Representational_state_transfer

Si necesita un servicio de estilo RPC, seguro, gRPC es excelente. Si desea vivir en la web, o desea todos los beneficios que vienen con un servicio de estilo RESTful, entonces cree un servicio de estilo RESTful. Y si es demasiado lento para serializar / deserializar datos en formato JSON en su servicio de descanso, está perfectamente bien usar protobuf o lo que sea.

Si gRPC es una versión 2 de algo, es una versión 2 de SOAP. Uno que no es terrible, como SOAP.

Y no, no puede simplemente "llamar a cualquier función" en su solicitud GET y tener un servicio RESTful.

Una última cosa: si va a usar protobufs sobre un servicio RESTful, hágalo bien, usando los encabezados de tipo de contenido, etc. Con eso, puede admitir fácilmente JSON Y protobuf.

Bajando de mi caja de jabón ahora ...;)