Aplicacion Rest Como hacerla

[mamcx]

Una aplicación REST no es tan diferente de una app normal, solo que agrega una forma diferente de serializacion & esta distribuida.

Como se explica en la tesis de como hacer apps robustas de forma distribuida:
(Del creador de ERLANG, un lenguaje donde las funciones locales se manejan tal como las remotas).
http://erlang.org/download/armstrong_thesis_2003.pdf

-----

Una app distribuida "simple" es casi lineal:

Cliente -> COMANDO -> Serializador -> RED -> Servidor -> Deserializador -> Ruteo -> COMANDO EN SERVIDOR -> RESPUESTA (y se invierte los pasos)

Todo entre Serializador y Ruteo son las cosas que se agregan al proceso.

Osea que hacer:

Código Delphi [-]
procedure sum(a,b:Integer):Integer

sum(a,b)

En ambos casos es "casi lo mismo".

SIN EMBARGO

El *verdadero shock* está en que en una app monolítica tienes un manejo invisible del "estado" del programa, y mutas libremente el contenido de la memoria. Ese manejo de estado es lo que te da el runtime/lenguaje. Por ejemplo, al hacer la llamada a SUM no tienes que conocer la dirección en memoria, y aun toda una INVISIBLE cantidad de "variable globales" como el STACK y el HEAP que mantienen todo vivo. Una ficción que se rompe de cuando en cuando al manifestarse en forma de bugs.

Esa ficcion no sirve en una app distribuida. Y como la mayoría de los lenguajes tienen un acceso global del programa, aun los programadores más cuidadosos tienen todo entrelazado por mas que intenten aislar o encapsular las cosas. Y cuando tratan de portar eso a una app distribuida se estrellan porque toda su intuición queda derrumbada, aunque juren que han sido programadores disciplinados.

Además, mientras en un monolito solo hay un "cliente", en una app distribuida hay que asumir no solo una posibilidad infinita, sino que los clientes pueden ser maliciosos.

Asi que tienes que:

1- Asumir que todo lo que llega al servidor puede venir de un cliente malicioso. Todo hay que validarlo.
2-Manejar de forma manual el estado, haciendo lo posible de no usarlo ("stateless").
3-Buscar hacer funciones "puras", al estilo de lenguajes funcionales, que no accedan nada "global" ni generen "side-effects"
4-Reducir al mínimo la cantidad de datos en la comunicación
5-Asumir que los clientes/servidores morirán a mitad, al principio, al final, llegando, dandose la vuelta, en todo momento.