gRPC vs. REST

En el gran atlas de Internet, las interfaces de programación de aplicaciones (API) son las carreteras que conectan ciudades, pueblos, playas y otros destinos. Las API permiten que las aplicaciones de software se comuniquen entre sí para intercambiar datos, características y funcionalidades. Un informe de Imperva de 2023 reveló que alrededor del 71 % del tráfico de Internet consistía en llamadas a la API, lo que demuestra lo vital que es esta tecnología para el funcionamiento de las aplicaciones y empresas modernas.

No es de extrañar que comprender cómo construir una API sea una habilidad fundamental para la mayoría de los desarrolladores. Pero, como corresponde a una infraestructura tan importante, existen múltiples variedades.

Para extender nuestra metáfora, una superautopista de 12 carriles no es “mejor” que una carretera de superficie de un solo carril; esa superautopista destruiría el tejido de un barrio urbano y esa carretera de superficie sería un desastre en una zona de mucho tráfico. Los diferentes estilos arquitectónicos para crear API, como REST y gRPC, son iguales: cada uno de ellos tiene fortalezas y debilidades, y comprender esas fortalezas y debilidades es vital para la creación de una infraestructura saludable.

Transferencia de estado representacional o REST es un conjunto de principios de diseño (o restricciones arquitectónicas): interfaz uniforme, disociación cliente-servidor, sin estado, capacidad de almacenamiento en caché, arquitectura de sistema en capas y código bajo pedido (opcional). Las API creadas utilizando estos principios se denominan API REST o API RESTful.

Las API REST pueden utilizar varios lenguajes de programación y formatos de datos, siempre que cumplan con los principios REST. Es la forma más común de construir una API.

Las API REST utilizan solicitudes HTTP (también conocidas como métodos HTTP) como GET, POST, PUT y DELETE para realizar funciones estándar de bases de datos. Estas operaciones se utilizan para crear, leer, actualizar y eliminar registros de recursos y, a menudo, se denominan "CRUD". Los recursos del lado del servidor se identifican mediante URL denominadas endpoints.

Por ejemplo, una API REST usaría una solicitud GET para recuperar un registro. Una solicitud POST crea un nuevo registro. Una solicitud PUT actualiza un registro y una solicitud DELETE elimina uno. Todos los métodos HTTP se pueden utilizar en las llamadas a la API. Una API REST bien diseñada es como un sitio web que se ejecuta en un navegador web con funcionalidad HTTP integrada.

La información de recursos se puede entregar a un cliente en muchos formatos de mensajería, incluidos JavaScript Object Notation (JSON), HTML, XLT, Python, PHP o texto sin formato. JSON es popular porque es legible tanto por humanos como por máquinas y es independiente del lenguaje de programación.

Más información sobre REST vs. GraphQL

Compatibilidad con navegadores: dado que las API REST utilizan métodos HTTP/1.1 y HTTP estándar, así como formatos como XML y JSON, son compatibles con los navegadores. 

Facilidad de uso: debido a su simplicidad y popularidad, se considera que REST es más fácil de entender, especialmente para principiantes. Las herramientas, los tutoriales y las guías abundan en GitHub y en otros lugares.

Flexibilidad: se considera que las API REST tienen un acoplamiento débil entre el cliente y el servidor. Esta flexibilidad permite realizar cambios más sencillos y rápidos: se puede hacer un cambio en cualquiera de las partes sin necesidad de modificar la otra.

Ecosistema sólido: las API REST tienen un número significativo de herramientas y un amplio soporte y documentación. La especificación OpenAPI u OAS, por ejemplo, proporciona una definición estándar del sector de los parámetros y capacidades de una API REST. La última versión de OAS, OAS 3.1, incluye compatibilidad total con JSON Schema, identificación estandarizada que utiliza el identificador SPDX y más.

Confianza en HTTP/1.1: Si bien el uso de HTTP/1.1 por parte de REST le da soporte universal para navegadores y cierta personalización en los encabezados, también priva a las API REST de algunos de los beneficios del nuevo HTTP/2. Los beneficios que faltan incluyen el streaming bidireccional; REST solo admite el streaming unario, en el que una solicitud va seguida de una respuesta.

Más lento y menos eficiente: como con HTTP/1.1, la confianza de REST en formatos como XML y JSON tiene inconvenientes y beneficios. Esos formatos son legibles por humanos, lo cual está bien, pero también son archivos comparativamente grandes, lo que significa una transmisión más lenta.

Requiere herramientas adicionales: el ecosistema de REST puede ser sólido, pero debe serlo, ya que algunas características no están integradas en la arquitectura. La generación de código, por ejemplo, está disponible en forma de complementos para REST, pero sigue siendo un paso adicional y con una complicación adicional.

gRPC es un marco de código abierto que Google desarrolló inicialmente como una implementación específica de llamada a procedimiento remoto o RPC. Ahora está gestionado por la Cloud Native Computing Foundation (CNCF).

gRPC podría significar o no "Llamada a procedimiento remoto de Google", ya que los desarrolladores insisten descaradamente en que podría significar "Llamada a procedimiento remoto gRPC" u otras posibilidades. En cualquier caso, gRPC, al igual que otros RPC, permite que las llamadas remotas aparezcan y funcionen como llamadas locales.

Como modelo para la interacción cliente/servidor, RPC se utiliza a menudo en el desarrollo de API. En un modelo RPC, el cliente interactúa con un intermediario comúnmente conocido como stub. Este stub convierte los datos para su transmisión y, una vez que recibe los resultados solicitados del servidor, los convierte de nuevo al formato original para el cliente. Hay muchos tipos diferentes de marcos RPC, incluidos XML-RPC y JSON-RPC.

Estos marcos RPC son ligeros, relativamente fáciles de usar y proporcionan beneficios como el desarrollo simplificado y la abstracción de la comunicación de red. Sin embargo, entornos como las arquitecturas de microservicios y los sistemas con altas cargas de datos a menudo requieren un marco de mayor rendimiento y gRPC se desarrolló para satisfacer esa necesidad.

gRPC utiliza un lenguaje de definición de interfaz (IDL) llamado Protocol Buffers (Protobuf) para serializar datos estructurados en binarios. Dado que el binario es más compacto que JSON o XML, esto permite la transferencia de cargas útiles más grandes a velocidades más rápidas.

gRPC también utiliza HTTP/2, que permite la transmisión bidireccional y convierte a gRPC en una opción sólida para las API en entornos distribuidos (especialmente aquellos que requieren comunicación en tiempo real), arquitecturas de microservicios, aplicaciones de transmisión y la conexión de dispositivos de Internet de las cosas (IoT).

Velocidad: gRPC, a través de Protobuf, serializa y deserializa datos de muchos lenguajes diferentes, incluidos Java, Python, Ruby y más, en una carga útil binaria para su transmisión. Este código es ligero, por lo que el tiempo de transmisión y la latencia en el intercambio de datos se reducen con las API de gRPC.

Generación de código: gRPC incluye un compilador Protobuf llamado [protoc], que ofrece características de generación de código nativo. Una vez definida la estructura de datos en un .proto gRPC puede generar código tanto del lado del cliente como del lado del servidor.

Compatibilidad con HTTP/2: basándose en el protocolo de transporte HTTP/2, gRPC admite varios tipos de transmisión. Por ejemplo, admite la transmisión bidireccional, en la que el cliente y el servidor pueden enviar mensajes de forma independiente en una secuencia de lectura/escritura, además de la transmisión por secuencias del lado del cliente y del lado del servidor.

Interceptores: gRPC admite middleware conocido como interceptores, que permiten una mayor funcionalidad. Se pueden instalar interceptores para implementar seguridad, autenticación, análisis de métricas y más.

Cancelación y tiempos de espera: gRPC admite la cancelación, también conocida como tiempos de espera o fechas límite (un tiempo específico después del cual se cancelará la llamada).

La novedad y el ecosistema: si bien el gRPC incluye características, como la generación de código, se trata de una arquitectura relativamente nueva, ya que no vio su lanzamiento inicial hasta 2016. Esa novedad ha dejado la documentación y el soporte limitados en comparación con los estilos arquitectónicos más antiguos.

Curva de aprendizaje pronunciada: algunos desarrolladores consideran que gRPC tiene una curva de aprendizaje más pronunciada en comparación con REST. Su serialización de datos binarios permite una comunicación eficaz, pero no es legible por los humanos.

Falta de compatibilidad del navegador: debido a que los navegadores web no admiten de forma nativa el protocolo gRPC, no es posible llamar directamente a un servicio gRPC desde una aplicación basada en navegador. Una forma de solucionar este problema es utilizar un proxy como gRPC-Web. gRPC-Web actúa esencialmente como una capa de traducción entre el protocolo HTTP y gRPC de un navegador.

REST y gRPC tienen muchos elementos en común y ambos se utilizan para crear sistemas escalables. Las similitudes incluyen:

Arquitectura cliente/servidor: gRPC y REST son arquitecturas cliente/servidor con un formato de solicitud-respuesta que permite a un cliente y un servidor comunicarse e intercambiar datos. En esta arquitectura, un cliente envía una solicitud y el servidor responde devolviendo los datos solicitados o realizando una acción solicitada.

Independiente de la plataforma: gRPC y REST permiten que los servicios creados en diferentes plataformas con diferentes sistemas operativos se comuniquen.

Sin estado: tanto REST como gRPC se consideran sin estado, lo que significa que cada solicitud incluye toda la información necesaria para completarla. El servidor no necesita almacenar ninguna información sobre solicitudes anteriores.

Soporte de idiomas: ambos estilos arquitectónicos son independientes del lenguaje, lo que significa que estas API pueden ser utilizadas por aplicaciones escritas en varios lenguajes de programación. Esta cualidad hace que ambos sean portátiles en todos los entornos de programación.

Uso de HTTP: tanto REST como gRPC se basan en la comunicación basada en HTTP. Sin embargo, gRPC utiliza HTTP/2, mientras que REST se basa en HTTP/1.1. Además, gRPC abstrae el protocolo de comunicación HTTP/2 subyacente, mientras que la comunicación HTTP se abstrae menos en REST.

Las diferencias clave entre REST y gRPC pueden ayudar a los desarrolladores a decidir cuál es mejor para la API que están creando. Esas diferencias incluyen:

Formato de datos: las API REST utilizan principalmente formatos basados en texto como JSON y XML. gRPC utiliza Protobuf para codificar datos en formato binario.

Patrón de comunicación: REST solo admite comunicación unaria, es decir, una solicitud seguida de una respuesta. gRPC es compatible con otras, como el streaming bidireccional (tanto el cliente como el servidor intercambian independientemente), el streaming del servidor (una sola solicitud desencadena varias respuestas) y el streaming del cliente (varias solicitudes dan como resultado una única respuesta).

Patrón de diseño: gRPC tiene un diseño orientado a servicios, en el que las operaciones de servidor invocables se definen como servicios o funciones. En REST, el diseño se orienta en torno a recursos, en los que se utilizan métodos HTTP para acceder a recursos del servidor a través de endpoints  definidos por URL.

Acoplamiento: el cliente y el servidor de gRPC están estrechamente acoplados, lo que significa que tanto el cliente como el servidor deben tener acceso al mismo archivo de proto de middleware. Cualquier cambio en uno requiere un cambio en el otro. REST está débilmente acoplado. Esta independencia significa que los cambios en un componente no afectan al otro.

Generación de código: gRPC ofrece generación de código integrada; REST no lo hace, aunque hay complementos disponibles.

Implementación: REST no requiere ningún software específico y, de hecho, es compatible con navegadores. gRPC requiere un software específico tanto en el lado del servidor como en el del cliente.

REST es una opción popular de diseño de API por una razón; su simplicidad, amplia compatibilidad y versatilidad lo convierten en una excelente opción para muchas aplicaciones. Para las API públicas, REST suele ser la opción más sensata, ya que se utiliza más y suele ser más fácil de entender. Muchos desarrolladores están más familiarizados con REST y pueden tener una infraestructura significativa específicamente para REST, incluidos servidores, herramientas de gestión de API, herramientas de desarrollo y varias herramientas de prueba.

REST también admite el almacenamiento en caché integrado o la capacidad de almacenar los datos a los que se accede con frecuencia, ya sea de forma local o mediante un proxy. El almacenamiento en caché puede mejorar significativamente la velocidad y la eficacia, aunque también debe incluir varios datos de validación, autenticación y caducidad.

REST también se prefiere generalmente para servicios web y API web, debido a su compatibilidad con HTTP/1.1 y su compatibilidad universal con navegadores. Por lo general, es preferible a gRPC para comunicaciones de datos más sencillas. Su acoplamiento flexible y su complejidad reducida pueden mejorar la escalabilidad de la arquitectura del sistema y ayudar a que un entorno sea más flexible con el tiempo. Sin embargo, esta adaptabilidad tiene un coste de rendimiento. 

gRPC es una arquitectura relativamente nueva, y los desarrolladores adoptan cada vez más su velocidad, eficiencia y herramientas integradas. A menudo se utiliza para aplicaciones de transmisión en tiempo real y API complejas que requieren un alto rendimiento y el manejo de altas cargas de datos en sistemas distribuidos. Aunque es más complejo que REST, el uso de HTTP/2 y Protobuf proporciona a gRPC una mayor escalabilidad del rendimiento. 

gRPC es muy adecuado para arquitecturas de microservicios, ya que su capacidad para transmitir datos bidireccionales en tiempo real permite que los diferentes microservicios dentro de una aplicación envíen y reciban de manera simultánea e independiente. También está viendo soporte en aplicaciones móviles debido a su transmisión de datos rápida y compacta y porque es menos probable que las aplicaciones móviles dependan de un navegador.

gRPC también es ideal para conectar elementos de IoT a API de backend, porque sus cargas útiles compactas, su baja latencia y su eficiencia de alto rendimiento funcionan bien con la tecnología de bajo consumo .