¿En qué se diferencia GRPC de REST?

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

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

rest grpc Jwan622
fuente

«Si es a través de la red ... ¿por qué se llama RPC?» - Porque RPC es una llamada a procedimiento remoto, y 'remoto' puede significar totalmente 'en otro host'.

weirdan

Respuestas:

104

La capa de transporte funciona utilizando HTTP / 2 sobre TCP / IP. Permite conexiones de menor latencia (más rápidas) que pueden aprovechar una sola conexión de cliente a 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 ponga en contacto de manera eficiente con el cliente para enviar mensajes (respuesta asíncrona / notificaciones, etc.)

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

+ ----------- + ---------------- +
| Verbo HTTP | CRUD |
+ ----------- + ---------------- +
| OBTENER | Leer |
| PUT | Actualizar / Reemplazar |
| PATCH | Actualizar / Modificar |
| BORRAR | Eliminar |
+ ----------- + ---------------- +

mientras que gRPC puede definir cualquier tipo de llamadas de función, incluidas síncronas / asincrónicas, unidireccionales / bidireccionales (flujos), etc.

Usando gRPC, el cliente realiza una llamada a un método local. Para el programador, parece que estás 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 fue llamado localmente.

gRPC se encarga de toda la plomería subyacente y simplifica el paradigma de programación. Sin embargo, para algunos puristas dedicados a REST, esto puede parecer una complicación excesiva. YMMV

mmccabe
fuente

Entonces, pregunta rápida: en REST, también puede llamar a cualquier tipo de función. Por ejemplo, en Rails, puedo enviar una solicitud GET a un punto final que no es RESTful y hacer algo además de obtener un recurso. Realmente puedo patear cualquier función desde ese punto final no RESTful. También puedo crear servicios en REST que parecen estar llamando a un método local, pero realmente bajo el capó está haciendo una llamada http a un punto final. Entonces, las diferencias no son tan grandes, ¿verdad? Al menos en la capa de transporte. ¿O son?

Jwan622

REST / RESTful se ejecuta en HTTP, gRPC se ejecuta en HTTP / 2 (como un WebSocket). Usando un generador de código de Swagger es posible generar stubs de cliente y servidor para REST, gRPC usa un archivo proto para generar sus stubs (no muy diferente al antiguo enfoque WSDL / SOAP). El archivo proto define el tipo, por lo que los stubs cliente / servidor generados son seguros para los tipos. En un dispositivo móvil, la conexión gRPC es eficiente, ya que puede compartir el mismo socket HTTP / 2 subyacente con cualquier otra conexión simultánea desde la aplicación móvil.

mmccabe

Aquí hay una buena introducción a gRPC: medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Aquí hay una demostración de gRPC: github.com/mmcc007/go

mmccabe

Jwan622 y mmccabe: Con la biblioteca Superglue 2.1, puedo construir una casa con manzanas y naranjas. En algún momento, tenemos que elegir la herramienta adecuada para el trabajo y siempre buscar minimizar la complejidad de nuestro sistema de software. Recuerde, eliminar el código siempre es una optimización del rendimiento;)

Martin Andersson

Desde mi perspectiva, cosas como las API RESTful siempre han sido un "truco" para seguir los protocolos antiguos. Si surge algo que me permite usar una pila más adecuada para los lenguajes modernos y aún ser independiente de qué lenguaje está siendo utilizado específicamente por un cliente Y aumentar el rendimiento de manera espectacular, ¡entonces seré la primera persona en subirse al tren!

Martin Andersson

REST no requiere JSON o HTTP / 1.1

Puede construir 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ían JSON a través de HTTP / 2

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

Los servicios RESTful no son un "truco" 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 caché de las solicitudes GET y la capacidad de reproducción de las solicitudes PUT).

gRPC, SOAP, et. todos son más como hacks: hacks en la parte superior de HTTP para hacer un túnel de servicios de estilo RPC a través de HTTP, para sortear 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 las cajas intermedias son difíciles de reemplazar.

Si no tiene tiempo para leer sobre 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, claro, gRPC es genial. Si desea vivir en la web, o desea todos los beneficios que vienen con un servicio de estilo RESTful, cree un servicio de estilo RESTful. Y si es demasiado lento 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 sea 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 tanto JSON como protobuf.

Saliendo de mi caja SOAP ahora ..;)

usuario2077221
fuente

¿Está insinuando que no se puede crear un servicio RESTful usando gRPC?

Kevin S

El RTFM que cita la tesis de Fielding fue exagerado, pero por lo demás una gran respuesta.

rmharrison

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, 'HTTP / 2 permite que el servidor "envíe" contenido' ...

Denis Wang
fuente

La inserción del servidor no necesita HTTP / 2.

Robin Green

¿Podrías ser más específico? Esta es la wiki que habla sobre HTTP / 2 Server Push: en.wikipedia.org/wiki/HTTP/2_Server_Push

Denis Wang

Lo siento, no me refiero a la inserción del servidor HTTP 2, me refiero a la transmisión de respuestas. Hay otras formas de transmitir respuestas, como la venerable encuesta larga o websockets, por ejemplo.

Robin Green

GRPC servidor no envía HTTP / 2 "ignora cliente de transmisión automática y GRPC HTTP / 2 "empuje" Así ventajas de GRPC heredada de HTTP / 2 no deben incluir. "empuje".

user675693