rest - grpc json gateway

REST vs gRPC: ¿cuándo debo elegir uno sobre el otro? (3)

Cuando se realiza correctamente, REST mejora la capacidad de evolución y la escalabilidad a largo plazo a costa del rendimiento y la complejidad agregada. REST es ideal para servicios que se deben desarrollar y mantener de forma independiente, como la propia Web. El cliente y el servidor se pueden acoplar libremente y cambiar sin romperse entre sí.

Los servicios de RPC pueden ser más simples y tener un mejor rendimiento, a costa de la flexibilidad y la independencia. Los servicios RPC son ideales para circunstancias en las que el cliente y el servidor están estrechamente acoplados y siguen el mismo ciclo de desarrollo.

Sin embargo, la mayoría de los llamados servicios REST no siguen realmente a REST, porque REST se convirtió en una simple palabra de moda para cualquier tipo de API HTTP. De hecho, la mayoría de las API REST están tan estrechamente acopladas que no ofrecen ninguna ventaja sobre un diseño RPC.

Por eso, mis respuestas un tanto cínicas a tu pregunta son:

Algunas personas están adoptando gRPC por la misma razón que adoptaron REST hace unos años: design-by-buzzword.
Muchas personas se están dando cuenta de que la forma en que implementan REST equivale a RPC, así que, ¿por qué no ir con un marco RPC estandarizado e implementarlo correctamente, en lugar de insistir en implementaciones REST deficientes?
REST es una solución para problemas que aparecen en proyectos que abarcan varias organizaciones y tienen objetivos a largo plazo. Tal vez las personas se están dando cuenta de que realmente no necesitan REST y están buscando mejores opciones.

Veo más y más organizaciones de software que usan gRPC en sus arquitecturas orientadas a servicios, pero la gente también sigue usando REST. ¿En qué casos de uso tiene sentido usar gRPC y cuándo tiene sentido usar REST para la comunicación entre servicios?

Curiosamente, me he encontrado con proyectos de código abierto que utilizan tanto REST como gRPC. Por ejemplo, Kubernetes y Docker Swarm utilizan gRPC hasta cierto punto para la coordinación de clústeres, pero también exponen las API REST para interactuar con los nodos maestro / líder. ¿Por qué no usar gRPC arriba y abajo?

Dependiendo de la futura hoja de ruta de la gRPC, la gente continuará migrando a ella y dejando REST (a través de HTTP) "silencioso".

gRPC es más conveniente de muchas maneras:

Usualmente rápido (como súper rápido)
(Casi) No hay "dicotomía de diseño": cuál es el punto final correcto a usar, cuál es el verbo HTTP correcto a usar, etc.
No lidiar con la complicada entrada / respuesta de serialización como gRPC trata con la serialización: codificación de datos más eficiente y HTTP / 2 que hace que las cosas vayan más rápido con solicitudes multiplexadas en una sola conexión y compresión de encabezado
Defina / declare su entrada / respuesta y genere clientes confiables para diferentes idiomas (por supuesto, los que son "compatibles", esto es una GRAN ventaja)
Conjunto formalizado de errores: esto es discutible, pero hasta ahora son más directamente aplicables a los casos de uso de API que los códigos de estado HTTP

En cualquier caso, tendrá que lidiar con todos los problemas de gRPC también, ya que nada en este mundo es infalible, pero hasta ahora "se ve mejor" que REST, y en realidad lo ha demostrado.

Creo que puedes tener lo mejor de ambos mundos. En cualquier caso, gRPC sigue en gran medida la semántica HTTP (sobre HTTP / 2), pero permite explícitamente la transmisión en dúplex completo, divergiendo de las convenciones típicas de REST, ya que utiliza rutas estáticas por motivos de rendimiento durante el envío de llamadas como análisis de parámetros de llamadas de rutas: parámetros de consulta y carga útil El cuerpo añade latencia y complejidad.

La promesa de REST siempre ha sido una interfaz uniforme . Un cliente REST ideal podría hablar con una amplia gama de recursos REST, incluso aquellos que no existían cuando el cliente estaba codificado.

Desafortunadamente, este ideal nunca se ha materializado realmente, excepto el estuche original de REST, la World Wide Web de documentos legibles por personas.

En este punto, la mayoría de las interfaces que se llaman a sí mismas "RESTful" son realmente un tipo de RPC barroco, donde los datos de solicitud y respuesta se manchan sobre métodos, cadenas de consulta, encabezados, códigos de estado, cargas útiles, todo en una variedad de formatos frágiles.

La mayor parte de la uniformidad en las interfaces "RESTful" de hoy está en las cabezas de los desarrolladores. Ellos "saben" que POST /orders/ probablemente va a agregar un nuevo pedido. Pero aún tienen que programar a sus clientes para "saber" que, por cada API con la que hablan, a menudo cometen muchos errores.

Sin embargo, hay cierta uniformidad que puede ser útil en el código. Por ejemplo, si tiene una API “RESTful”, a menudo puede agregar una capa de almacenamiento en caché transparente y que se puede ajustar de manera casi gratuita. Esto es posible porque los mensajes HTTP (semánticamente correctos) ya llevan toda la información estandarizada necesaria para el almacenamiento en caché: método de solicitud, URL, código de estado, Cache-Control , Vary y todo eso. En gRPC, tienes que rodar tu propio almacenamiento en caché.

Pero la verdadera razón para el predominio actual de "REST" no es este tipo de posibilidades menores. Es realmente solo el éxito de la World Wide Web. En algún momento de la historia, se supo que todos ya tenían un servidor HTTP flexible y con rendimiento (para servir a su sitio web) y un cliente HTTP sólido (para ver dicho sitio), por lo que cuando la gente comenzó a agregar recursos legibles por máquina, fue simplemente Más fácil y más barato mantener las mismas formas HTTP. Utilizaron métodos HTTP, encabezados y códigos de estado porque eso es lo que sus servidores web ya entendieron y registraron. Herramientas como PHP les permitieron hacer esto con una sobrecarga de implementación cero en sus sitios web normales.

Si la uniformidad y la alineación con World Wide Web no son importantes para usted, entonces RPC es una opción arquitectónica probada y verdadera, y gRPC es una implementación sólida que puede ahorrarle algunos problemas, como explica uıɥɔɐɯ.