¿Por qué REST se usa comúnmente en lugar de mecanismos similares a RPC en aplicaciones web?

Comencé muy recientemente en una empresa que utiliza un marco personalizado bastante inusual para sus aplicaciones web, al menos en comparación con los marcos de aplicaciones web típicos que conozco. En lugar de un servicio web RESTful, se utiliza un mecanismo RPC para comunicarse con el servidor.

La comunicación con el servidor parece una simple llamada a la función, pero la función se ejecuta en el servidor, no en el cliente. En el lado del servidor, hay una manera de definir qué funciones puede llamar el cliente. Los detalles de cómo se traduce esto en solicitudes http se abstraen por completo.

Solo he usado esto por poco tiempo, pero parece bastante conveniente. Pero me pregunto qué inconvenientes de este enfoque me estoy perdiendo. Todos los demás parecen estar haciéndolo de manera diferente, lo que generalmente es una señal para mí de que podría estar haciendo algo estúpido o brillante, con probabilidades mucho más altas de lo primero.

REST fue diseñado para la web, y la web fue diseñada para REST. Los dos encajan perfectamente juntos. La tesis doctoral de Roy Fielding de 2000, Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red definió e introdujo el término REST , y existe una interacción significativa entre la web y REST: Roy Fielding trabajó en HTTP / 1.1, del cual es el autor principal, y usó lo que aprendió allí para describir REST en su disertación.

Entonces, la razón simple por la cual la web y REST van tan bien juntos es que la definición de REST se extrajo de cómo funciona la web, y la web es una implementación de REST.

Es por eso que REST es una buena opción para servicios web y aplicaciones web: porque simplemente hace las mismas cosas que ya han demostrado que funcionan en la web "humana" y las aplica a la web "máquina".

El gran problema con RPC (dependiendo de la implementación exacta ) radica básicamente en las Falacias de la Computación Distribuida , que Arnon Rotem-Gal-Oz explica con más detalle en este documento técnico :

1. La red es confiable
2. La latencia es cero
3. El ancho de banda es infinito
4. La red es segura
5. La topología no cambia
6. Hay un administrador
7. El costo de transporte es cero
8. La red es homogénea.

Todos estos son supuestos que los recién llegados suelen hacer cuando comienzan a crear sistemas distribuidos. Por supuesto, todos ellos son falsos. Y debe tenerlos en cuenta al crear sistemas distribuidos.

El problema con muchas implementaciones de RPC es que intentan hacer que las llamadas remotas se vean como llamadas locales. Pero no se parecen en nada:

• una llamada local nunca falla; la subrutina a la que llamó puede fallar, pero la llamada en sí misma nunca falla : una llamada remota puede perderse en la red
• una llamada local es instantánea; la subrutina que llamó puede ejecutarse durante mucho tiempo (o incluso para siempre si se atasca en un bucle infinito), pero la llamada en sí no toma tiempo (bueno, un puñado de instrucciones de CPU a lo sumo, menos si la llamada es en línea, pero es muy rápido): una llamada remota puede atascarse en la red durante mucho tiempo
• Si la subrutina regresa normalmente, el resultado siempre regresa; con una llamada remota, el resultado puede perderse en la red
• los retornos son instantáneos: los resultados remotos pueden viajar en la red durante mucho tiempo
• si llamo a una subrutina una vez, se ejecutará exactamente una vez: una llamada remota puede perderse en la red o duplicarse, por lo que la rutina remota puede ejecutarse entre 0 y cualquier número de veces
• Obtengo exactamente un resultado: un resultado remoto puede perderse o duplicarse, por lo que puede obtener el resultado 0 o más veces
• si llamo a una subrutina dos veces, obtengo dos resultados y obtengo el resultado de la primera llamada antes que el resultado de la segunda llamada; probablemente ya pueda adivinarlo: con RPC, es posible que no obtenga resultados, o solo el primero , o solo el segundo, o el segundo antes del primero, o el primero puede perderse y obtienes el segundo dos veces, o al revés, y así sucesivamente ...
• si llamo ay luego b, obtengo el resultado de ay luego el resultado de b : esta es solo una versión más general del punto anterior, con RPC, puede obtener cualquiera de las dos respuestas 0 o más veces en cualquier orden

Usted va a tener que lidiar con todo lo anterior para una llamada remota. Pero si su marco hace que las llamadas remotas no se puedan distinguir de las llamadas locales, entonces no puede , porque no sabe cuáles son las llamadas remotas. El marco puede tratar de manejar todo eso por usted, pero el problema es: el marco no sabe tanto sobre su sistema como usted. No sabe si hay llamadas en las que realmente no importa si una se pierde de vez en cuando. Entonces, el marco debe ser muy defensivo, y eso es costoso en términos de latencia y ancho de banda.

Especialmente porque el marco en realidad no puede protegerte. El teorema de CAP dice que un sistema distribuido no puede ser consistente, disponible y tolerante a la partición al mismo tiempo; más precisamente, dice que una vez que ocurre una Partición, el sistema no puede continuar siendo Consistente y Disponible, tiene que elegir uno (contrario a la creencia popular, el teorema no dice que no puede tener los tres, cuando el sistema está funcionando normalmente, puede tener los tres; pero una vez que tenga una Partición, debe elegir uno de los otros dos). El teorema de PACELC extiende el teorema de CAP al mostrar que incluso cuando el sistema está funcionando, debe compensar la latencia frente a la consistencia.

Estas son compensaciones importantes de las que el marco no puede protegerte, ya que son específicas del dominio e importantes para el diseño central.

Contrasta esto con un enfoque como Erlang de, que hace el trabajo: en Erlang, todo mensaje envía son tratados como remota, incluso si son locales. Esto significa que siempre está preparado para lidiar con todos los problemas anteriores (y muchos más). Para los procesos locales, éstos no representan un poco de una sobrecarga, sin embargo. Para ayudar con esto, hay una gran cantidad de herramientas, marcos, bibliotecas, patrones y expresiones idiomáticas para tratar el manejo y la supervisión de errores.

No ha descrito cómo funciona su marco RPC en particular, y qué idioma o bibliotecas está utilizando, pero tengo una fuerte sospecha de que pertenece al tipo anterior "pretender que la red no existe". Esos simplemente no funcionan. Está bien eliminar la distinción entre llamadas locales y remotas tratando todo como una llamada remota . Si lo hace al revés, los resúmenes son demasiado: la red es parte de su sistema, si lo abstrae, abstrae algo que realmente necesita saber.

Ahora, si tiene que usar REST específicamente o no, esa es una pregunta completamente diferente. Como expliqué anteriormente, la web fue diseñada para REST y REST fue diseñada para la web, por lo que los dos tienen sentido juntos, pero puede usar otros estilos arquitectónicos, si lo desea. Pero al menos parte de su pregunta fue sobre "por qué no RPC", y expuse las razones anteriores, más precisamente le expliqué por qué el tipo de RPC que sospecho que está usando puede causarle problemas.

Ya hay varias buenas ideas en los comentarios, que repetiré aquí:

1. RPC es típicamente específico de la tecnología.
2. Lo que más les interesa a los desarrolladores es JSON, no REST.

JSON tiene algunas cualidades muy buenas. Es simple, fácil de leer para un humano, fácil de analizar para una computadora, y Javascript lo reconoce instantáneamente de forma nativa (siendo, ya sabes, notación de objeto Javascript ).

Si está dispuesto a renunciar a restricciones como REST, puede hacer casi cualquier cosa que desee con JSON, incluidas las llamadas a procedimientos remotos. Todo lo que tiene que hacer es establecer un protocolo adecuado. De hecho, dicho protocolo ya existe: JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC y REST son solo enfoques diferentes con pros y contras, y ambos son valiosos según el contexto. REST se describe mejor para trabajar con los recursos, mientras que RPC es más sobre las acciones. Los clientes RPC están estrechamente vinculados con la implementación del servicio de varias maneras y se hace muy difícil cambiar la implementación del servicio sin interrumpir a los clientes.