¿Cuál es la diferencia entre gRPC y REST?
gRPC y REST son dos formas de diseñar una API. Una API es un mecanismo que permite a dos componentes de software comunicarse entre sí mediante un conjunto de definiciones y protocolos. En gRPC, un componente (el cliente) llama o invoca funciones específicas en otro componente de software (el servidor). En REST, en lugar de llamar a funciones, el cliente solicita o actualiza datos en el servidor.
¿Qué es gRPC?
¿Qué es RPC?
En RPC, las comunicaciones cliente-servidor funcionan como si las solicitudes de la API del cliente fueran una operación local o la solicitud fuera un código de servidor interno.
En RPC, un cliente envía una solicitud a un proceso del servidor que siempre está atento a las llamadas remotas. En la solicitud, contiene la función del servidor a la que llamar, junto con los parámetros que se deben pasar. Una API de RPC usa un protocolo como HTTP, TCP o UDP como mecanismo de intercambio de datos subyacente.
¿En qué se diferencia gRPC de RPC?
gRPC es un sistema que implementa la RPC tradicional con varias optimizaciones. Por ejemplo, gRPC usa búferes de protocolo y HTTP 2 para la transmisión de datos.
También abstrae el mecanismo de intercambio de datos del desarrollador. Por ejemplo, otra implementación de API de RPC muy utilizada, OpenAPI, requiere que los desarrolladores asignen conceptos de RPC al protocolo HTTP. Sin embargo, gRPC abstrae la comunicación HTTP subyacente. Estas optimizaciones hacen que gRPC sea más rápida, fácil de implementar y más compatible con la web que otras implementaciones de RPC.
¿Qué es REST?
REST es un enfoque de arquitectura de software que define un conjunto de reglas para intercambiar datos entre los componentes de software. Se basa en HTTP, el protocolo de comunicación estándar de la web. Las API de RESTful administran las comunicaciones entre un cliente y un servidor a través de verbos HTTP, como POST, GET, PUT y DELETE para las operaciones de creación, lectura, actualización y eliminación. El recurso del lado del servidor se identifica mediante una URL conocida como punto de conexión.
REST funciona de la siguiente manera:
- El cliente hace una solicitud para crear, modificar o eliminar un recurso en el servidor
- La solicitud contiene el punto de conexión del recurso y también puede incluir parámetros adicionales.
- El servidor responde y devuelve todo el recurso al cliente una vez que se completa la operación.
- La respuesta contiene datos en formato JSON y códigos de estado
Las API creadas con las directrices de REST se denominan API de RESTful o API de REST.
¿Por qué las organizaciones usan gRPC y REST?
gRPC y REST son dos enfoques diferentes para desarrollar API.
Una API funciona de manera similar a pedir comida de un restaurante con un menú. En cualquier restaurante, los consumidores (cliente) pueden pedir comida del menú (API), que tiene un conjunto fijo de platos. Esto se comunica a la cocina (servidor) que prepara el plato solicitado y lo envía al cliente. El cliente no necesita saber cómo la cocina prepara el pedido, solo qué esperar a cambio. La estandarización de los formatos de los menús significa que los clientes y las cocinas saben cómo usarlos.
Sin las API, no habría un acuerdo compartido sobre cómo se comunican las diferentes aplicaciones o servicios de software. Los programadores de dos aplicaciones distintas necesitarían hablar entre sí para determinar cómo desarrollar el intercambio de datos en cada ocasión.
Existen diferentes tipos de arquitecturas API, como gRPC y REST, ya que cada una de ellas puede ser mejor para diferentes casos de uso dentro de una organización. Un diseñador de API debe elegir su arquitectura cliente-servidor preferida en función de los requisitos del sistema.
¿Cuáles son las similitudes entre gRPC y REST?
REST y gRPC comparten algunas similitudes innatas como enfoques arquitectónicos de API.
Mecanismo de intercambio de datos
Ambos permiten que dos componentes de software, un cliente y un servidor, se comuniquen e intercambien datos en función de un conjunto de reglas compartidas. Estas reglas se aplican independientemente de cómo funcione internamente cada componente de software.
Comunicación basada en HTTP
Ambos transfieren datos a través del mecanismo de solicitud-respuesta HTTP, el protocolo de comunicación eficiente preferido de la web. Sin embargo, en gRPC, esto está oculto para el desarrollador, mientras que en REST es más evidente.
Flexibilidad de implementación
Puede implementar tanto REST como gRPC en una amplia gama de lenguajes de programación. Esta cualidad hace que ambos sean altamente portables en todos los entornos de programación. Esto lleva a una interoperabilidad óptima con un soporte casi universal.
Idoneidad para sistemas distribuidos y escalables
Tanto gRPC como REST utilizan lo siguiente:
- Comunicación asincrónica, para que el cliente y el servidor puedan comunicarse sin interrumpir las operaciones
- Diseño sin estado, por lo que el servidor no tiene que recordar el estado del cliente
Esto significa que los desarrolladores pueden usar gRPC y REST para crear sistemas resistentes a errores con una gran cantidad de solicitudes simultáneas. Puede crear sistemas distribuidos y escalables con varios clientes.
Principios arquitectónicos de gRPC y REST
Si bien REST y gRPC ofrecen una función similar, los modelos subyacentes difieren significativamente en su arquitectura.
Modelo de comunicación
Con una API de REST, un cliente envía una única solicitud de API de REST a un servidor y, a continuación, el servidor envía una única respuesta. El cliente debe esperar a que el servidor responda antes de continuar con las operaciones. Este mecanismo es un modelo de solicitud-respuesta y es una conexión de datos unaria (uno a uno).
Por el contrario, con gRPC, un cliente puede enviar una o varias solicitudes de API al servidor, lo que puede generar una o varias respuestas del servidor. Las conexiones de datos pueden ser unarias (de uno a uno), de transmisión de servidor (de uno a muchos), de cliente (de muchos a uno) o de streaming bidireccional (de muchos a muchos). Este mecanismo es un modelo de comunicación de respuesta al cliente y es posible porque la gRPC se basa en HTTP 2.
Operaciones invocables en el servidor
En una API de gRPC, las operaciones de servidor invocables se definen mediante servicios, también conocidos como funciones o procedimientos. El cliente gRPC invoca estas funciones como si se llamara a una función internamente dentro de una aplicación. Esto se conoce como diseño orientado a servicios. A continuación se muestra un ejemplo:
createNewOrder(customer_id, item_id, item_quantity) -> order_id
En REST, hay un conjunto limitado de verbos de solicitud HTTP que el cliente puede usar en los recursos del servidor definidos por una URL. El cliente llama al recurso en sí. Esto se conoce como diseño orientado a entidades. El diseño orientado a entidades se alinea bien con los métodos de programación orientados a objetos. A continuación se muestra un ejemplo:
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
Si bien puede diseñar las API de gRPC con un enfoque orientado a las entidades, esto no es una limitación del sistema en sí.
Formato de intercambio de datos
Con una API de REST, las estructuras de datos que se transfieren entre los componentes de software suelen expresarse en formato de intercambio de datos JSON. Es posible pasar otros formatos de datos como XML y HTML. JSON es fácil de leer y es flexible, aunque debe ser serializado y traducido a un lenguaje de programación.
Por el contrario, gRPC usa el formato Protocol Buffers (Protobuf) de forma predeterminada, aunque también ofrece soporte nativo para JSON. El servidor define una estructura de datos mediante el lenguaje de descripción de la interfaz (IDL) del búfer de protocolo en un archivo de protoespecificación. Después, gRPC serializa la estructura en formato binario y, a continuación, la deserializa en cualquier lenguaje de programación especificado. Este mecanismo lo hace más rápido que el uso de JSON, que no se comprime durante la transmisión. Los búferes de protocolo no son legibles por humanos, a diferencia de una API de REST que se usa con JSON.
Otras diferencias clave entre gRPC y REST
Otras diferencias clave entre gRPC y REST
Más allá del estilo arquitectónico, gRPC y REST tienen otras diferencias inherentes.
Acoplamiento cliente-servidor
REST está débilmente acoplado, lo que significa que el cliente y el servidor no necesitan saber nada sobre la implementación del otro. Este acoplamiento flexible facilita la evolución de la API a lo largo del tiempo. Esto se debe a que un cambio en las definiciones del servidor no requiere necesariamente un cambio de código en el cliente.
gRPC está estrechamente acoplado, lo que significa que el cliente y el servidor deben tener acceso al mismo archivo .proto. Cualquier actualización del archivo requiere actualizaciones tanto en el servidor como en el cliente.
Generación de código
gRPC ofrece una selección integrada de funciones de generación de código nativo del lado del cliente y del lado del servidor. Están disponibles en varios lenguajes gracias a protoc, el compilador de Protocol Buffers. Tras definir la estructura en el archivo .proto, gRPC genera el código del lado del cliente y del lado del servidor. La generación de código hace que el desarrollo de la API consuma menos tiempo.
Por otro lado, REST no ofrece ningún mecanismo de generación de código integrado, por lo que los desarrolladores deben usar herramientas adicionales de terceros si requieren esta característica.
Streaming bidireccional
gRPC ofrece una comunicación de streaming bidireccional. Esto significa que tanto el cliente como el servidor pueden enviar y recibir múltiples solicitudes y respuestas simultáneamente en una sola conexión.
REST no ofrece esta característica.
Cuándo usar gRPC en lugar de REST
REST es actualmente la arquitectura de API más popular para arquitecturas de servicios web y microservicios. La popularidad de REST se debe a su sencilla implementación y asignación, legibilidad y flexibilidad de la estructura de datos. Es fácil para los nuevos programadores empezar a desarrollar API de RESTful para sus aplicaciones, ya sea para el desarrollo de servicios web o para microservicios internos.
Estos son los casos de uso de una API de REST:
- Arquitecturas basadas en la web
- API orientadas al público para que los usuarios externos puedan entenderlas fácilmente
- Comunicaciones sencillas de datos
gRPC, a diferencia de REST, se diseñó específicamente para permitir a los desarrolladores crear API de alto rendimiento para arquitecturas de microservicios en centros de datos distribuidos. Es más adecuado para sistemas internos que requieren transmisión en tiempo real y grandes cargas de datos. gRPC también es una buena opción para arquitecturas de microservicios que comprenden varios lenguajes de programación cuando es poco probable que la API cambie con el tiempo.
Una API de gRPC es mejor para estos casos de uso:
- Sistemas con un alto nivel de rendimiento
- Cargas de datos elevadas
- Aplicaciones en tiempo real o de streaming
Nota sobre el desarrollo de software web
Si bien HTTP es el protocolo web principal, existen diferentes versiones de HTTP con distintos grados de adopción en los navegadores web y los servidores web.
Una API de gRPC siempre usa HTTP 2, y una API de REST normalmente usa HTTP 1.1, que no es el mismo protocolo HTTP. Si bien HTTP 2 es ahora un protocolo web común, no tiene compatibilidad universal con los navegadores, a diferencia de HTTP 1.1. Esta compatibilidad limitada con los navegadores puede hacer que gRPC sea una opción menos atractiva para los desarrolladores que buscan la compatibilidad con aplicaciones web.
Resumen de las diferencias entre gRPC y REST
| API de gRPC |
API de REST |
|
| ¿Qué es? |
Un sistema para crear y usar API basado en el modelo de comunicación cliente-servidor de llamada a procedimiento remoto (RPC). |
Un conjunto de reglas que define el intercambio de datos estructurados entre un cliente y un servidor. |
| Enfoque de diseño |
Diseño orientado a servicios. El cliente solicita al servidor que realice un servicio o función que puede afectar o no a los recursos del servidor. |
Diseño orientado a entidades. El cliente pide al servidor que cree, comparta o modifique los recursos. |
| Modelo de comunicación |
Varias opciones como unario, un servidor para muchos clientes, un cliente para muchos servidores y muchos clientes para muchos servidores. |
Unario. Un único cliente se comunica con un único servidor. |
| Implementación |
Requiere el software gRPC tanto en el lado del cliente como en el del servidor para funcionar. |
Puede implementarlo en el lado del cliente y del servidor en una amplia variedad de formatos sin necesidad de un software común. |
| Acceso a los datos |
Llamadas de servicio (función). |
Varios puntos de conexión en forma de URL para definir los recursos. |
| Datos devueltos |
En el tipo de retorno fijo del servicio, tal como se define en el archivo de búfer de protocolo. |
En una estructura fija (normalmente JSON), definida por el servidor. |
| Acoplamiento cliente-servidor |
Estrechamente acoplado. Tanto el cliente como el servidor necesitan el mismo archivo de búfer de protocolo que define el formato de los datos. |
Débilmente acoplado. El cliente y el servidor no conocen los detalles internos. |
| Generación automática de códigos |
Función integrada. |
Requiere herramientas de terceros. |
| Streaming bidireccional |
Presente. |
No está presente. |
| Más adecuada para lo siguiente: |
Arquitecturas de microservicios de alto rendimiento o con muchos datos. |
Orígenes de datos simples donde los recursos están bien definidos. |
¿Cómo puede AWS cumplir con sus requisitos de gRPC y REST?
Amazon Web Services (AWS) cuenta con una gama de servicios y herramientas para ayudar a los diseñadores de API a crear, ejecutar y administrar aplicaciones y servicios modernos basados en API. Para obtener más información, consulte cómo crear aplicaciones modernas en AWS.
Estos son algunos ejemplos de ofertas de AWS que pueden cumplir con sus requisitos de API:
- Amazon API Gateway permite a los desarrolladores crear, publicar y administrar las API a escala. Con API Gateway, puede crear API de RESTful optimizadas para aplicaciones web y arquitecturas de microservicios en contenedores.
- Elastic Load Balancing (ELB) distribuye el tráfico de red para mejorar la escalabilidad de las aplicaciones. Puede enrutar y equilibrar la carga del tráfico de gRPC entre microservicios o entre clientes y servicios habilitados para gRPC. Esto permite incorporar sin problemas la administración del tráfico gRPC en sus arquitecturas sin modificar la infraestructura subyacente de sus clientes o servicios.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice es un servicio de redes de aplicaciones que conecta, monitorea y protege de forma coherente las comunicaciones entre sus servicios. Escale automáticamente los recursos de computación y de red para admitir cargas de trabajo HTTP, HTTPS y gRPC de gran ancho de banda.
Cree una cuenta hoy mismo para comenzar a utilizar gRPC y REST en AWS.
