gRPC frente a 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 funcionalidad. Un informe de Imperva de 2023 encontró que alrededor del 71 % del tráfico de Internet consistía en llamadas a API, lo que demuestra cuán vital 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 ampliar nuestra metáfora, una superautopista de 12 carriles no es "mejor" que una carretera de superficie de un solo carril; esa supercarretera destruiría el tejido de un vecindario urbano y esa carretera superficial sería un desastre en un área de mucho tráfico. Los diferentes estilos arquitectónicos para crear API, como REST y gRPC, funcionan de la misma manera: cada uno tiene fortalezas y debilidades, y comprender esas fortalezas y debilidades es vital para la creación de una infraestructura saludable.

La transferencia de estado representacional, o REST, es un conjunto de principios de diseño (o restricciones arquitectónicas): interfaz uniforme, desacoplamiento cliente-servidor, apatridia, capacidad en caché, arquitectura de sistema en capas y código bajo demanda (opcional). Las API creadas con estos principios se denominan API REST o API RESTful.

Las API REST pueden emplear 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 base de datos. Estas operaciones se utilizan para crear, leer, actualizar y eliminar registros de recursos y, a menudo, se las denomina “CRUD”. Los Recursos del lado del servidor se identifican mediante URL llamadas 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 incorporada.

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

Aprenda más sobre REST vs. GraphQL

Soporte del navegador: Debido a que las API REST utilizan HTTP/1.1 y métodos HTTP estándar, así como formatos como XML y JSON, es compatible con navegadores. 

Facilidad de uso: debido a su simplicidad y popularidad, REST es ampliamente visto como 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 flexible entre el cliente y el servidor. Esta flexibilidad permite cambios más simples y rápidos: se puede realizar un cambio en cualquier lado sin requerir un cambio en el otro.

Ecosistema robusto: 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 de la industria de los parámetros y capacidades de una API REST. La última versión de OAS, OAS 3.1, incluye compatibilidad total con el esquema JSON, identificación estandarizada que emplea 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 HTTP/2 más nuevo. Los beneficios que faltan incluyen la transmisión bidireccional; REST solo soporta streaming unario, en el que una solicitud es seguida por una respuesta.

Más lento y menos eficiente: al igual que con HTTP/1.1, La dependencia de REST en formatos como XML y JSON viene con inconvenientes y beneficios. Estos formatos son legibles para humanos, lo cual es bueno, 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 robusto, pero necesita 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 plug-ins para REST, pero eso sigue siendo un paso extra, con una complicación extra.

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 o no significar "Llamada a procedimiento remoto de Google", ya que los desarrolladores insisten descaradamente en que podría significar "Llamada a procedimiento remoto de gRPC" u otras posibilidades. En cualquier caso, gRPC, al igual que otras 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 infraestructuras RPC, incluidos XML-RPC y JSON-RPC.

Estos marcos RPC son livianos, relativamente fáciles de usar y brindan 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 una infraestructura 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 (particularmente 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 que se define la estructura de datos en un .proto gRPC puede generar código tanto del lado del cliente como del servidor.

Compatibilidad con HTTP/2: Basar en el protocolo de transporte HTTP/2, gRPC admite varios tipos de streaming. Por ejemplo, admite el streaming bidireccional, en el que el cliente y el servidor pueden enviar mensajes de forma independiente en un flujo de lectura/escritura, además del streaming 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 soporta cancelación, también conocida como tiempos de espera o plazos: un tiempo especificado después del cual se cancelará la llamada.

Novedad y ecosistema: si bien gRPC incluye características adicionales, como la generación de código, es una arquitectura relativamente nueva, ya que solo vio su lanzamiento inicial en 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 que REST. La serialización binaria de los datos permite una comunicación eficaz, pero no es legible.

Falta de compatibilidad con el 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 permiten que un cliente y un servidor se comuniquen e intercambien 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 dela 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.

Compatibilidad con otros lenguajes: Ambos estilos arquitectónicos son agnósticos en cuanto al lenguaje, lo que significa que estas API pueden ser empleadas por aplicaciones escritas en varios lenguajes de programación. Esta cualidad hace que ambos sean portables en distintos entornos de programación.

Uso de HTTP: tanto REST como gRPC dependen de la comunicación basada en HTTP. Sin embargo, gRPC usa 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 soporta otros, incluyendo transmisión bidireccional (intercambio de cliente y servidor de forma independiente), transmisión de servidores (una sola solicitud desencadena múltiples respuestas) y transmisión de clientes (múltiples solicitudes dan como resultado una sola respuesta).

Patrón de diseño: gRPC tiene un diseño orientado a servicios, en el que las operaciones del servidor invocables se definen como servicios o funciones. En REST, el diseño está orientado a los recursos, en el que se emplean métodos HTTP para acceder a los recursos del servidor a través de puntos finales 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 prototipo 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, aunque hay plug-ins disponibles.

Implementación: REST no requiere software específico y, de hecho, soporta navegadores. gRPC requiere software específico tanto en el lado del servidor como 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 usa más ampliamente y, a menudo, se entiende más fácilmente. Muchos desarrolladores están más familiarizados con REST y pueden tener una infraestructura significativa específicamente para REST, incluidos servidores, API management herramientas, herramientas de desarrollo y varias herramientas de prueba.

REST también admite el almacenamiento en caché incorporado, o la capacidad de almacenar datos a los que se accede con frecuencia, ya sea localmente o VIA®  un proxy. El almacenamiento en caché puede mejorar significativamente la velocidad y la eficiencia, aunque también debe incluir diversa información 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 pueden ayudar a que un entorno sea más flexible con el tiempo. Sin embargo, esta adaptabilidad tiene un costo 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 streaming en tiempo real y API complejas que requieren alto rendimiento y el manejo de altas cargas de datos en sistemas distribuidos. Si bien es más complejo que REST, el uso de HTTP/2 y Protobuf le da a gRPC una mayor escalabilidad de rendimiento. 

gRPC es muy adecuado para arquitecturas de microservicios, ya que su capacidad para transmitir datos bidireccionales en tiempo real permite que los diferentes servicios dentro de una aplicación envíen y reciban de forma 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, la baja latencia y la eficiencia de rendimiento combinan bien con la Tecnología Power® .