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 :
- La red es confiable
- La latencia es cero
- El ancho de banda es infinito
- La red es segura
- La topología no cambia
- Hay un administrador
- El costo de transporte es cero
- 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
a
y luego b
, obtengo el resultado de a
y 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.