Comprender gRPC, OpenAPI y REST, y cuándo usarlos en el diseño de APIs (2020)

Gestión de API

gRPC y REST: comprensión de gRPC, OpenAPI y REST en el diseño de APIs, y cuándo usar cada uno

• Modelos de diseño de API: En el diseño de APIs se usan principalmente dos modelos: RPC y REST. La mayoría de las APIs modernas se implementan sobre el protocolo HTTP.
• gRPC: Tecnología de implementación de APIs RPC que usa HTTP 2.0 como protocolo de transporte. Google y otras empresas usan con frecuencia APIs que combinan las ideas de RPC y HTTP.
• Tres formas principales de usar HTTP:
  1. REST: El cliente usa tal cual las URL que ofrece el servidor, sin necesidad de entender su formato.
  2. gRPC: Usa HTTP/2, pero HTTP no queda expuesto al diseñador de la API.
  3. OpenAPI: El cliente invoca la API usando plantillas de rutas URL.

REST

• Características: El cliente no necesita entender el formato de la URL, y la URL no forma parte de la especificación de la API.
• Ventajas: Tiene las ventajas de la web, como estabilidad, consistencia y universalidad. El modelo orientado a entidades es más simple y fácil de entender.

gRPC

• Características: Usa HTTP/2, pero los detalles de HTTP quedan ocultos. El cliente usa la API llamando procedimientos y pasando parámetros.
• Ventajas: Es fácil generar bibliotecas de programación del lado del cliente y ofrece buen rendimiento.

OpenAPI

• Características: Invoca la API usando plantillas de rutas URL, por lo que el cliente debe entender el formato de la URL.
• Ventajas: Se puede acceder a la API solo con tecnologías HTTP estándar. También se pueden generar bibliotecas de programación del lado del cliente.

Comparación entre gRPC y OpenAPI

• Similitudes: Ambos pueden usarse como lenguaje de definición de interfaces RPC (IDL).
• Diferencias: gRPC oculta los detalles de HTTP, mientras que OpenAPI los expone.

Ventajas de REST

• Modelo orientado a entidades: Es más simple, más fácil de entender y se mantiene estable con el paso del tiempo.

Cómo usar OpenAPI

• Definición de rutas: La API se define usando rutas y métodos HTTP.

Ventajas y desventajas de OpenAPI

• Ventajas: Es similar al modelo RPC, por lo que resulta familiar para los programadores. Puede mapearse a solicitudes HTTP.
• Desventajas: Diseñar los detalles de HTTP requiere bastante esfuerzo.

Ventajas de gRPC

• Implementación simple: La implementación del lado del servidor es sencilla y es fácil generar bibliotecas del lado del cliente.
• Rendimiento: Es eficiente gracias al uso de payloads binarios.

Desventajas de gRPC

• Necesidad de software especializado: Tanto el cliente como el servidor necesitan software especializado.
• Funcionalidad limitada en proxies: A diferencia de una API HTTP, es difícil ampliar o modificar funciones desde un proxy.

Conclusión

• Elección del diseño de API: Hay que elegir entre REST, OpenAPI y gRPC considerando las ventajas y desventajas de cada uno.
• Aspectos a considerar al usar gRPC: Es ventajoso en APIs internas o cuando no es necesario que los clientes adopten la tecnología gRPC.

[GN⁺]

Opiniones de Hacker News

• Me arrepiento de haber aprendido gRPC. Se me fue muchísimo tiempo en depuración y ajuste de configuración

  • Se supone que gRPC oculta la complejidad interna, pero en la práctica requiere mucha depuración y ajuste de configuración
  • Perdí mucho tiempo con el plugin de Maven, problemas de compatibilidad con HTTP/2 y temas de firewall
  • La documentación es deficiente, y fue difícil hacer observables los mensajes de error

• Llevo mucho tiempo construyendo APIs y he usado tanto gRPC como HTTP/REST

  • Me parece extraño distinguir entre OpenAPI y REST como si fueran cosas opuestas
  • OpenAPI es una forma de documentar cómo funciona una API HTTP, y puede expresar APIs RESTful
  • gRPC es un mecanismo RPC que intercambia Protocol Buffers
  • gRPC es eficiente, pero no es tan potente como las bibliotecas HTTP

• He trabajado en FAANG y creo que gRPC es útil para el enrutamiento de servicios internos

  • Los protocolos RPC permiten trabajar a gran escala y a alta velocidad
  • Pero si fuera algo orientado a clientes o a la web, no usaría gRPC

• A menos que se use streaming bidireccional, creo que gRPC es una pérdida de tiempo

  • Para hacer llamadas RPC entre servicios implementados en distintos lenguajes, hace falta mucho middleware

• En un proyecto se adoptó gRPC por motivos de rendimiento, pero después se cambió a una API JSON

  • Faltaba experiencia con gRPC, y el proyecto fracasó por varios problemas

• Al usar connectrpc, se están resolviendo varios problemas de gRPC

  • Con buf.build es fácil importar archivos proto de terceros
  • La función de generación automática de SDK es muy útil

• Creo que la experiencia de desarrollo con gRPC es peor que con REST

  • Se necesitan herramientas adicionales y el código cliente generado es complejo

• Roy Fielding mencionó que para una API REST basta con conocer el URI inicial y los media types estandarizados

• No me gusta usar gRPC dentro del centro de datos

  • El rendimiento no es tan alto y la calidad de los clientes open source es baja
  • En APIs basadas en web prefiero la legibilidad de JSON, aunque existen problemas de incompatibilidad de tipos

• Sentí que gRPC es difícil de adoptar fuera de Google

  • El cliente gRPC JS es pesado y poco transparente
  • Frente a la simplicidad de REST, me parece que la ejecución salió mal