Compartir a través de

Comparación entre los servicios gRPC y las API HTTP

  • Artículo

Nota:

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 9 de este artículo.

Advertencia

Esta versión de ASP.NET Core ya no se admite. Para obtener más información, consulta la Directiva de soporte técnico de .NET y .NET Core. Para la versión actual, consulta la versión .NET 8 de este artículo.

Importante

Esta información hace referencia a un producto en versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

Para la versión actual, consulte la versión de .NET 9 de este artículo.

Por James Newton-King

En este artículo se realiza una comparación entre los servicios gRPC y las API HTTP con JSON (incluidas las API web de ASP.NET Core). La tecnología que se usa para proporcionar una API para la aplicación es una decisión importante, y gRPC ofrece ventajas exclusivas en comparación con las API HTTP. En este artículo se describen las ventajas y los inconvenientes de gRPC, y se recomiendan escenarios para usar gRPC antes que otras tecnologías.

Comparación general

En la tabla siguiente se ofrece una comparación general de las características entre gRPC y las API HTTP con JSON.

Característica gRPC API HTTP con JSON
Contrato Requerido (.proto) Opcional (OpenAPI)
Protocolo HTTP/2 HTTP
Payload Protobuf (pequeño, binario) JSON (grande, legible para usuarios)
Carácter preceptivo Especificación estricta Flexible. Cualquier HTTP es válido.
Streaming Cliente, servidor, bidireccional Cliente, servidor
Compatibilidad con exploradores No (requiere grpc-web) Sí
Seguridad Transporte (TLS) Transporte (TLS)
Generación de código de cliente Sí OpenAPI + herramientas de terceros

Ventajas de gRPC

Rendimiento

Los mensajes de gRPC se serializan mediante Protobuf, un formato de mensaje binario eficaz. Protobuf se serializa muy rápidamente en el servidor y el cliente. La serialización de Protobuf genera cargas de mensajes pequeñas, un aspecto importante en escenarios de ancho de banda limitado como las aplicaciones móviles.

gRPC está diseñado para HTTP/2, una revisión principal de HTTP que proporciona importantes ventajas de rendimiento con respecto a HTTP 1.x:

  • Tramas binarias y compresión. El protocolo HTTP/2 es compacto y eficaz tanto para el envío como para la recepción.
  • Multiplexación de varias llamadas HTTP/2 a través de una única conexión TCP. La multiplexación elimina el bloqueo de encabezado de línea.

HTTP/2 no es exclusivo de gRPC. Muchos tipos de solicitud, incluidas las API HTTP con JSON, pueden usar HTTP/2 y beneficiarse de sus mejoras de rendimiento.

Generación de código

Todos los marcos de trabajo de gRPC proporcionan compatibilidad de primera clase con la generación de código. Un archivo principal para el desarrollo de gRPC es el archivo .proto, en el que se define el contrato de servicios y mensajes de gRPC. A partir de este archivo, los marcos gRPC generan el código de una clase base de servicio, mensajes y un cliente completo.

Mediante el uso compartido del archivo .proto entre el servidor y el cliente, los mensajes y el código de cliente se pueden generar de un extremo a otro. La generación de código del cliente elimina la duplicación de mensajes en el cliente y el servidor, y crea de forma automática un cliente fuertemente tipado. Al no tener que escribir un cliente se ahorra considerablemente tiempo de desarrollo en las aplicaciones con muchos servicios.

Especificación estricta

No existe una especificación formal para la API HTTP con JSON. Los desarrolladores debaten el mejor formato de las direcciones URL, los verbos HTTP y los códigos de respuesta.

La especificación gRPC es preceptiva con respecto al formato que debe seguir un servicio gRPC. gRPC elimina el debate y ahorra tiempo de desarrollo, ya que es coherente entre las plataformas y las implementaciones.

Streaming

HTTP/2 proporciona una base para las secuencias de comunicación en tiempo real de larga duración. gRPC proporciona compatibilidad de primera clase para el streaming a través de HTTP/2.

Un servicio gRPC admite todas las combinaciones de streaming:

  • Unario (sin streaming)
  • Streaming del servidor al cliente
  • Streaming del cliente al servidor
  • Streaming bidireccional

Fecha límite o tiempos de expiración y cancelación

gRPC permite a los clientes especificar cuánto tiempo están dispuestos a esperar a que se complete una RPC. La fecha límite se envía al servidor y este puede decidir qué acción realizar si supera la fecha límite. Por ejemplo, es posible que el servidor cancele las solicitudes de gRPC, HTTP o base de datos en curso si se alcanza el tiempo de expiración.

La propagación de la fecha límite y la cancelación mediante llamadas secundarias de gRPC ayuda a aplicar los límites de uso de recursos.

gRPC se adapta perfectamente a los escenarios siguientes:

  • Microservicios: gRPC está diseñado para la comunicación de baja latencia y rendimiento alto. gRPC resulta idóneo para microservicios ligeros en los que la eficiencia sea crítica.
  • Comunicación punto a punto en tiempo real: gRPC tiene una excelente compatibilidad con el streaming bidireccional. Los servicios gRPC pueden insertar mensajes en tiempo real sin sondeos.
  • Entornos políglotas: las herramientas de gRPC admiten todos los lenguajes de desarrollo más populares, lo que convierte a gRPC en una buena opción para entornos de varios lenguajes.
  • Entornos restringidos de red: los mensajes gRPC se serializan con Protobuf, un formato de mensaje ligero. Un mensaje gRPC siempre es más pequeño que un mensaje JSON equivalente.
  • (IPC) : los transportes de IPC, como los sockets de dominio de Unix y las canalizaciones con nombre, se pueden usar con gRPC para la comunicación entre aplicaciones en el mismo equipo. Para más información, consulte Comunicación entre procesos con gRPC.

Inconvenientes de gRPC

Compatibilidad limitada con exploradores

En la actualidad no es posible llamar directamente a un servicio gRPC desde un explorador. gRPC usa intensamente características de HTTP/2 y ningún explorador proporciona el nivel de control requerido a través de solicitudes web para admitir un cliente de gRPC. Por ejemplo, los exploradores no permiten que el autor de la llamada exija el uso de HTTP/2, ni proporcionan acceso a los marcos HTTP/2 subyacentes.

gRPC en ASP.NET Core ofrece dos soluciones compatibles con el explorador:

  • gRPC-Web permite a las aplicaciones de explorador llamar a servicios gRPC con el cliente gRPC-Web y Protobuf. gRPC-Web requiere que la aplicación del explorador genere un cliente gRPC. gRPC-Web permite que las aplicaciones de explorador saquen partido del uso de red de alto rendimiento y bajo nivel de gRPC.

    .NET tiene compatibilidad integrada con gRPC-Web. Para obtener más información, consulte gRPC-Web en aplicaciones gRPC de ASP.NET Core.

  • La transcodificación gRPC de JSON permite a las aplicaciones de explorador llamar a servicios gRPC como si fueran API RESTful con JSON. No es necesario que la aplicación de explorador genere un cliente gRPC o que disponga de información sobre gRPC. Se pueden crear API de RESTful automáticamente desde servicios gRPC, anotando para ello el archivo .proto con metadatos HTTP. La transcodificación permite que una aplicación admita API web de JSON y gRPC, sin duplicar el esfuerzo de tener que crear servicios independientes para cada uno de ellos.

    .NET tiene compatibilidad integrada para crear API web de JSON desde servicios gRPC. Para obtener más información, consulta Transcodificación JSON de gRPC en aplicaciones gRPC de ASP.NET Core.

Nota:

La transcodificación JSON de gRPC requiere .NET 7 o posterior.

No es legible por el usuario

Las solicitudes de API HTTP se envían como texto y se pueden leer y crear por parte de los usuarios.

De forma predeterminada, los mensajes gRPC se codifican con Protobuf. Aunque Protobuf es eficaz para el envío y la recepción, su formato binario no es legible. Protobuf requiere la descripción de la interfaz del mensaje especificada en el archivo .proto para deserializarse correctamente. Se requieren herramientas adicionales para analizar las cargas de Protobuf en la conexión y redactar las solicitudes a mano.

Existen características como la reflexión del servidor y la herramienta de línea de comandos de gRPC para ayudar con los mensajes de Protobuf binarios. Además, los mensajes de Protobuf admiten la conversión a y desde JSON. La conversión de JSON integrada proporciona una manera eficaz de convertir los mensajes de Protobuf a y desde formato legible durante la depuración.

Escenarios de marcos alternativos

En los escenarios siguientes se recomiendan otros marcos de trabajo antes que gRPC:

  • API accesibles de explorador: gRPC no se admite de forma completa en el explorador. gRPC-Web puede ofrecer compatibilidad con el explorador, pero tiene limitaciones e introduce un proxy de servidor.
  • Retransmisión de la comunicación en tiempo real: gRPC admite la comunicación en tiempo real a través de streaming, pero no existe el concepto de retransmisión de un mensaje a las conexiones registradas. Por ejemplo, en un escenario de salón de chat en el que se deben enviar nuevos mensajes de chat a todos los clientes, es necesario que cada llamada gRPC transmita de forma individual los nuevos mensajes de chat al cliente. SignalR es un marco útil para este escenario. SignalR tiene el concepto de conexiones persistentes y compatibilidad integrada para la retransmisión de mensajes.

Recursos adicionales