Es posible que hayas escuchado palabras como REST cuando se trata de desarrollo de software. REST es una arquitectura de API muy utilizada, y los desarrolladores la usan ampliamente para diseñar APIs de software. Las interfaces de programación de aplicaciones son vitales para cualquier aplicación de software, y REST es una de las muchas arquitecturas que se utilizan para las API.
En la actualidad, gRPC está ganando popularidad, y también pretende resolver algunos problemas tradicionalmente asociados a las APIs deREST . Pero, ¿en qué se diferencian? ¿Y cuál debería utilizar para su aplicación? Para saber la respuesta a estas preguntas, necesitamos entender más sobre gRPC frente a REST y en qué escenarios funcionan mejor. Pero antes de entrar en todo eso, veamos qué son las APIs y qué aportan a los microservicios.
¿Qué es una API?
Las aplicaciones de software pueden interactuar y comunicarse entre sí mediante el uso de interfaces de programación de aplicaciones (API), que funcionan como mediadores técnicos. Una API se encarga de enviar la solicitud de un usuario al sistema, que a su vez recibe una respuesta de éste.
Imagínese que va a pedir un teléfono por Internet. Vas a un sitio vinculado a la web, y éste envía información sobre tu consulta a un servidor. El servidor obtiene entonces la información, la analiza y, tras realizar los pasos necesarios, nos responde con los detalles que aparecen en nuestra pantalla. Esto es posible con las APIs.
La API describe cómo realizar esas peticiones de los clientes, qué estructuras de datos utilizar y las normas que deben cumplir los clientes. También describe los tipos de consultas que un programa puede enviar a otro. Ambos estilos de arquitectura, gRPC vs REST estilos de arquitectura son ampliamente utilizados para diseñar APIs.
APIs y microservicios
Las aplicaciones pueden tener una arquitectura monolítica o una arquitectura de microservicios. En una aplicación monolítica, todas las funciones y módulos del software están contenidos en una sola unidad o base de código. Una aplicación de microservicios, en cambio, consta de numerosas unidades más pequeñas que interactúan entre sí a través de interfaces como el protocolo HTTP.
El principal problema del estilo monolítico es que resulta más difícil cambiar, actualizar y ampliar el sistema a medida que los ingenieros añaden nuevas funciones y servicios sobre la base preexistente. Un cambio en un aspecto de la aplicación puede tener un efecto perjudicial en otras secciones. El código de un monolito se vuelve gradualmente tan entrelazado y difícil de comprender después de ser escalado, actualizado y cambiado numerosas veces que se requiere un rediseño completo del sistema.
Este problema se resuelve con los microservicios. Este diseño arquitectónico divide un monolito en sus componentes constitutivos, cada uno de los cuales se ejecuta como una aplicación independiente. Cada una de estas aplicaciones se denomina microservicio. A continuación, estos distintos microservicios se conectan mediante APIs. Esta colección de microservicios enlazados por APIs se une para construir un diseño de arquitectura mayor. Las APIs permiten la conexión y comunicación entre cada componente incorporado en una arquitectura de microservicios. Algunos enfoques populares para crear APIs son GraphQL, RPCy REST.
¿Qué es RPC?
Una RPC - Remote Procedure Call - es una arquitectura web que permite ejecutar un servicio en un servidor remoto mediante un formulario predefinido y obtener una respuesta con el mismo formato. El estilo del servidor que realiza la consulta, ya sea un servidor local o remoto, no se tiene en cuenta por RPC diseño.
Fuente de la imagen itrelease.com/Autor Junaid Rehman
La función básica de una RPC solicitud de API es la misma que la de una API de REST. Las RPC solicitudes de la API especifican las pautas de interacción y las técnicas que hacen posible la interacción. Posteriormente, el usuario llama a estas funciones utilizando parámetros. La cadena de solicitud de las URL contiene los parámetros utilizados para llamar a las operaciones.
Para crear las peticiones de la API, el RPC sistema utiliza una estructura cliente-servidor. RPC interpreta la información que el usuario solicita y la transmite al servidor. Mientras las comunicaciones internas de los servidores están ocultas, el servidor responde al usuario. El modelo RPC modelo también permite que un usuario solicite un servicio de forma particular. RPC tiene la ventaja de soportar las llamadas a procedimientos remotos tanto en escenarios descentralizados como en los locales.
¿Qué es REST?
REST - Representational State Transfer - se refiere a una arquitectura cliente-servidor en la que los usuarios tienen acceso a la información del backend a través de JSON o comunicación XML. Una API se considera RESTful si:
- Tiene una interfaz consistente y proporciona recursos particulares de la app a los clientes de la API.
- El servidor y el cliente trabajan por separado e independientemente. Sólo los URIs que apuntan a los componentes de la aplicación son conocidos por el cliente.
- No tiene estado. Esto significa que sólo el cliente guarda cualquier información de estado. El servidor no guardará ningún dato de estado sobre la consulta del cliente.
- Los activos de la aplicación proporcionados por la API deben ser almacenables en caché.
- Tiene una arquitectura en capas.
Es una aplicación de los diseños arquitectónicos contemporáneos que dependen de varias restricciones para permitir la transmisión de datos en redes hipermedia. Una API web RESTful necesita argumentos codificados por URL para conectarse a servicios que utilizan protocolos HTTP. REST Las APIs han sido ampliamente adoptadas en el diseño web contemporáneo para crear APIs sin estado, extensibles y fiables.
Cada componente que combina el sistema de microservicios puede mostrarse al usuario o al cliente como un recurso cuando la API REST se hace accesible públicamente. Este recurso puede consultarse mediante los comandos HTTP GET, POST, PUT y DELETE .
¿Cómo funciona REST?
REST utiliza el protocolo HTTP como protocolo de comunicación por defecto cuando trabaja con servicios que se especifican en las solicitudes de la API. Un recurso es algo comparable a un objeto en el diseño orientado a objetos. El recurso RESTful tiene acciones y atributos, como un objeto. En general, las implementaciones de REST suelen dar menos importancia a las acciones RESTful y, en cambio, se concentran más en los atributos de un recurso. Las soluciones RESTful son aquellas que sólo utilizan atributos para representar un recurso RESTful.
En una API RESTful, el usuario envía una consulta a una URL - Localizador Uniforme de Recursos, que provoca una respuesta con una carga útil en JSON, XML o cualquier formato de datos compatible. Esta carga útil representa el recurso que desea el usuario. Las peticiones comunes de los clientes incluyen
- Un método HTTP que especifica lo que debe procesarse en el recurso
- La ruta del recurso
- La cabecera que contiene datos sobre la consulta
- Una carga útil de mensaje específica del cliente
En el campo Accept de la cabecera, el usuario especifica los tipos de datos que es capaz de recibir. El servidor de la API envía una cabecera de tipo de contenido que identifica el formato de entrega del mensaje empleado en el cuerpo de la respuesta junto con la carga útil de datos que entrega al usuario que realiza la consulta. También se incluye en el cuerpo de la respuesta un código de respuesta que informa al usuario del estado del resultado de la llamada a la API.
¿Qué es gRPC?
gRPC - Google Remote Procedure Call - es un subtipo del diseño RPC. gRPC es una arquitectura global de alto rendimiento y de código abierto RPC que garantiza la flexibilidad y la velocidad de la arquitectura de microservicios. Las llamadas a funciones se utilizan gRPC para garantizar la interacción con el cliente en los microservicios creados con varios lenguajes de codificación.
Esta técnica implementa las peticiones de la API en RPC utilizando el estándar HTTP 2.0, pero ni el servidor ni el programador de la API tienen conocimiento de HTTP. Como resultado, la complicación disminuye porque no hay que preocuparse por cómo se traducen los principios de RPC a HTTP.
La llamada a procedimientos remotos de Google pretende acelerar la transferencia de datos entre microservicios. Para permitir la devolución y la llamada remotas, se basa en una estrategia que identifica un servicio, establece las metodologías y especifica las variables pertinentes.
Además, utiliza un IDL -lenguaje de descripción de interfaces- para especificar el paradigma de la API RPC, lo que simplifica la identificación de las funciones remotas. El IDL emplea por defecto Protocol Buffers para definir la interfaz del servicio y el formato de los mensajes de carga útil.
¿Cómo funciona gRPC funciona?
El protocolo HTTP/2, el streaming y los búferes de protocolo o protobufs son utilizados por gRPC APIs para transmitir mensajes. Un estándar de serialización llamado protobuf permite la creación automática de bibliotecas de usuario y la construcción sencilla de microservicios. En los archivos proto, los diseñadores de APIs describen las operaciones y los mensajes que se envían entre servidores y clientes.
El compilador de protoc carga los archivos y crea el software de usuario y servidor para comunicarse con los servicios remotos. En comparación con los formatos XML o JSON, los mensajes codificados con búferes de protocolo son considerablemente más pequeños, lo que hace que el procesamiento sea menos intensivo en CPU.
Además, el uso de HTTP/2, gRPC las API aportan varias mejoras al diseño de RPC. El protocolo añade una capa de formato binario que divide los paquetes en mensajes más pequeños con marco binario, lo que los hace transportables y pequeños. La ejecución de muchas llamadas dentro de un mismo canal es posible gracias al soporte de HTTP/2 para múltiples consultas simultáneas con la arquitectura de comunicación bidireccional.
El protocolo de transporte HTTP/2 admite múltiples flujos simultáneos, pero gRPC Las APIs amplían esta funcionalidad a través de los canales. Cada canal puede albergar varios flujos que se ejecutan simultáneamente a través de muchas conexiones concurrentes. Los canales ofrecen un método sencillo para conectarse al servidor de la API en una dirección y un puerto determinados. También se puede realizar un stub de cliente a través de los canales.
gRPC vs REST: comparación
Google creó gRPC como una variante de RPC para hacer frente a algunas de las limitaciones de los estilos de arquitectura de API existentes. Resuelve algunos problemas asociados a las APIs de REST, pero gRPC Las APIs se enfrentan a ciertos problemas debido a que es una tecnología más reciente. Hay muchos casos de uso en los que las API de REST pueden ser más adecuadas para tu aplicación. Puedes decidir cuál de estas APIs puede funcionar mejor con tu software una vez que conozcas las diferencias entre ambas.
HTTP 1.1 frente a HTTP 2
El enfoque solicitud-respuesta utilizado por las APIs de REST se basa principalmente en HTTP 1.1. Esto significa que el modelo debe procesar cada consulta individualmente si un microservicio recibe muchas consultas de múltiples clientes, lo que arrastra todo el sistema. REST Las APIs pueden desarrollarse sobre HTTP 2, pero como la arquitectura de comunicación sigue siendo petición-respuesta, no pueden aprovechar plenamente las ventajas de HTTP 2, como la compatibilidad bidireccional y la interacción en flujo.
gRPC Las API no se enfrentan a este reto. Se adhiere a un modelo de conexión cliente-respuesta y se basa en HTTP 2. gRPC puede aceptar muchas consultas de varios clientes y procesar esas peticiones al mismo tiempo mediante el flujo de información. Estas circunstancias permiten una comunicación bidireccional con interacción en flujo. Además, gRPC soporta interacciones unarias como las creadas por HTTP 1.1.
gRPC Las APIs pueden gestionar:
- Interacciones unarias
Si un cliente realiza una única petición, pero sólo se da una respuesta a cambio. - Streaming de servidor
Se conoce como streaming de servidor cuando un servidor responde a una consulta del cliente con un flujo de mensajes. El servidor también envía un mensaje de estado para concluir el procedimiento después de proporcionar todos los datos. - Streaming de cliente
Se produce cuando el cliente entrega una secuencia de mensajes y el servidor responde con un único mensaje. - Streaming bidireccional
Permite la transmisión de datos en ambos sentidos, ya que los canales del servidor y del cliente son independientes el uno del otro.
Compatibilidad con los navegadores
Dado que la mayor parte de la interacción de la API web se produce en línea, la compatibilidad con el navegador es una consideración clave en el debate entre gRPC vs. REST. La compatibilidad con los navegadores es probablemente una de las principales ventajas de las APIs REST frente a gRPC. Todos los navegadores ofrecen la capacidad completa de la API REST y la compatibilidad con el navegador. Sin embargo, la funcionalidad de gRPC en los navegadores, sin embargo, sigue siendo relativamente restringida. Lamentablemente, las transiciones entre HTTP 1.1 y HTTP 2 necesitan gRPC-web así como una capa proxy. Como resultado, gRPC Las APIs tienden a terminar siendo utilizadas principalmente para sistemas internos o privados, por ejemplo, en aplicaciones API empleadas para la información y funcionalidad del backend de organizaciones específicas.
Con el protocolo HTTP/2 se utilizan flujos multiplexados. Como resultado, numerosos clientes pueden enviar consultas en paralelo sin necesidad de abrir una nueva sesión TCP para cada uno. Además, el servidor puede utilizar el enlace existente para entregar los mensajes a los clientes.
El modelo de transferencia de estado representativo cuenta con un amplio apoyo de los navegadores porque integra HTTP 1.1. HTTP 1.1, que permite REST, utiliza un método de handshaking TCP para cada consulta. REST Por ello, las APIs suelen tener problemas de latencia, ya que el handshake lleva tiempo.
La estructura de datos de la carga útil
Si nos fijamos en la estructura de datos de la carga útil al ver gRPC vs REST, gRPC Las APIs serializan los datos de la carga útil utilizando Protocol Buffers por diseño. Este método es más ligero, ya que hace que los mensajes sean más pequeños y permite una estructura muy comprimida. Los búferes de protocolo están en formato binario; por lo tanto, para el intercambio de datos, serializa y deserializa la información. Protobuf puede traducir automáticamente mensajes muy escritos a los lenguajes de programación del cliente y del servidor.
RESTSin embargo, la mayoría de las veces se utiliza JSON o formularios XML para entregar y recibir información. JSON es el formato más utilizado por su adaptabilidad y capacidad para comunicar datos dinámicos sin atenerse a una estructura precisa, aunque no requiere ninguna. La calidad de lectura humana de JSON, que Protobuf aún no puede igualar, es otra ventaja importante.
JSON no es, sin embargo, tan rápido o ligero cuando se trata de la transferencia de datos. Esto se debe al requisito de que JSON debe ser serializado y traducido a los lenguajes de programación empleados tanto en el extremo del servidor como del cliente cuando se utiliza REST. Se trata de un paso adicional en el proceso de transmisión de datos, que podría perjudicar la eficiencia y aumentar la probabilidad de errores.
Generación de código
Los ingenieros deben emplear herramientas de terceros, como Postman, para la generación de código para las consultas de la API, ya que, a diferencia de gRPCla API REST carece de funciones de generación de código integradas. Por el contrario, , gRPC ofrece funciones de generación de código nativo gracias a su compilador protoc, que admite muchos lenguajes de programación. La generación de código es especialmente ventajosa para los microservicios que combinan numerosos servicios creados en múltiples plataformas y lenguajes. En general, su generación de código integrada facilita la construcción del kit de desarrollo de software (SDK).
REST La API, por otro lado, no proporciona funciones de generación de código nativo. Debe utilizar un programa de terceros para producir la generación de código para las llamadas a la API en varios idiomas. Aunque no es una molestia, es importante tener en cuenta que gRPC no depende de ningún otro servicio para la generación de código.
Cuándo utilizar las API de REST
Al comparar gRPC frente a REST, las APIs más empleadas y más populares para la integración de infraestructuras construidas sobre microservicios son las APIs de REST. REST Es probable que las APIs sigan siendo la opción por defecto para la conexión de aplicaciones durante mucho tiempo, independientemente de si se está creando una red interna o una plataforma abierta que abre sus activos al resto del mundo. REST Las APIs también son perfectas para los sistemas que requieren una rápida iteración y los estándares del protocolo HTTP.
REST Las APIs podrían ser su primera opción para el desarrollo de servicios web, microservicios e interfaces de aplicaciones porque las tecnologías de terceros las soportan universalmente. A diferencia de gRPCtiene una amplia compatibilidad con los navegadores y no se limita a los sistemas privados. Esto puede hacer que las APIs de REST sean muy útiles en muchos contextos.
También es más fácil de aprender REST, ya que cuenta con una amplia documentación sobre la API disponible en Internet. Esta curva de aprendizaje más sencilla es muy importante si tienes poco tiempo. Puedes ahorrarte mucho tiempo investigando y aprendiendo y empezar a implementar inmediatamente. Las APIs RESTful también son más fáciles de integrar en las aplicaciones. También ofrecen una mejor escalabilidad. Si quieres ampliar tu aplicación pronto, puede que sea mejor utilizar las APIs de REST. La falta de estado y confidencialidad puede causar problemas con la transferencia de estado representacional en ciertas aplicaciones. Si su aplicación tiene una opción de pago, gRPC puede ser una mejor opción.
Cuándo utilizar gRPC APIs
Tanto en gRPC vs REST, la mayoría de las herramientas de terceros todavía no proporcionan una funcionalidad integrada para gRPC cumplimiento. En consecuencia, gRPC las API se utilizan sobre todo para crear sistemas o estructuras internas inaccesibles para los usuarios externos. Teniendo en cuenta esta calificación, las siguientes situaciones podrían hacer uso de gRPC APIs:
- Conexiones de microservicios
gRPC Las APIs son especialmente útiles para enlazar arquitecturas formadas por microservicios ligeros en los que la eficacia de la entrega de mensajes es crucial debido a su baja latencia y a la rapidez de la comunicación del ancho de banda.
- Sistemas multilingües
gRPC destaca en el manejo de las comunicaciones en un contexto políglota gracias a su capacidad de generación de código nativo para una amplia gama de lenguajes de programación.
- Transmisión en tiempo real
Si la comunicación en tiempo real es necesaria, su sistema puede transmitir y recibir datos en tiempo real sin tener que esperar a la interacción cliente-respuesta unitaria gracias a la capacidad de gRPC para manejar el streaming bidireccional.
- Redes de bajo consumo y bajo ancho de banda
Estas redes pueden beneficiarse del uso de sesiones Protobuf serializadas por parte de gRPC, ya que proporcionan una comunicación ligera, una mayor eficiencia y rapidez. Por ejemplo, una red que se beneficiaría de la gRPC API es el Internet de las cosas.
¿Cómo ayuda AppMaster?
La programación ha cambiado mucho en las últimas décadas, con nuevas tecnologías y marcos que facilitan las tareas de los desarrolladores. La generación de No-code lleva esto al siguiente nivel. La gente no tiene que pasar por empinadas curvas de aprendizaje y puede desarrollar aplicaciones más rápidamente con no-code plataformas como AppMaster.
AppMaster le ayuda a crear el código fuente desde cero según las necesidades específicas de su aplicación. El código generado te pertenecerá, y podrás modificarlo según tus necesidades. Puedes crear los distintos módulos que necesita tu aplicación con AppMaster. Esto es mucho menos costoso y requiere menos tiempo que conseguir que todo un equipo de desarrollo haga lo mismo.
Los desarrolladores pueden enviar consultas entre la arquitectura de microservicios del backend utilizando el gRPC utilizando la plataforma de generación de no-code de AppMaster. Añadiremos la API tanto a gRPC desarrollo de servicios web como a las gRPC aplicaciones móviles el año siguiente para aumentar gRPC el soporte.
Conclusión
En el pasado, la transferencia de estado representativo era el enfoque más utilizado en el desarrollo de API. Pero entre gRPC vs REST, gRPC las APIs se están haciendo poco a poco más populares. A pesar de las diversas características que la hacen destacar, algunos problemas, como la falta de soporte de los navegadores y de documentación de las API, dificultan su empleo en todas partes. Sin embargo, con los avances tecnológicos y el crecimiento de la comunidad, podemos esperar que gRPC supere los retos actuales.
Por último, elegir entre REST o gRPCo incluso cualquiera de las otras metodologías de API como GraphQL o SOAP, depende de las necesidades específicas de tu proyecto. Algunas aplicaciones pueden necesitar las ventajas que gRPC ofrece, mientras que otras podrían requerir la funcionalidad básica que proporciona REST. Tienes que evaluar las funciones de tu aplicación y los casos de uso para elegir entre estas dos tecnologías capaces.
