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.

[ASAPLTDA]

Gracias a todos por sus respuestas.
VEo que falta mucho por aprender.

Me gustaría recibir ampliaciones sobre el tema y que todos los floristas aprendamos sobre esta tecnología por ejemplo
1. cuando uno hace en delphi el servidor rest y el cliente es un programa hecho en otro lenguaje se hace de forma diferente
1.1 para exponer una función que existe en el servidor rest , que información debe proveer el servidor para que un cliente externo use la funcion ?

[jhonny]

Empezado por ASAPLTDA

Gracias a todos por sus respuestas.
VEo que falta mucho por aprender.

Me gustaría recibir ampliaciones sobre el tema y que todos los floristas aprendamos sobre esta tecnología por ejemplo
1. cuando uno hace en delphi el servidor rest y el cliente es un programa hecho en otro lenguaje se hace de forma diferente
1.1 para exponer una función que existe en el servidor rest , que información debe proveer el servidor para que un cliente externo use la funcion ?

1. Así el cliente esté creado también en Delphi, debes hacer el server, como si estuvieras desarrollando para un cliente hecho en otro Lenguaje. Para mí, esa es una de las claves de éxito importantes para llevar a cabo una solución así.
1.1 Debes entregarle la documentación y ejemplos necesarios con el esquema JSON con el que se enfrentarán.

[mamcx]

Empezado por ASAPLTDA

1. cuando uno hace en delphi el servidor rest y el cliente es un programa hecho en otro lenguaje se hace de forma diferente

Cada lenguaje tiene sus propios idomas y formas de resolver las cosas, pero en el caso de REST es mas un protocolo, asi que al final la estructura general es la misma. Recuerda que se usa HTTP(o similar) y un metodo de paso de datos como Json/ProtocolBuffers/CVS/etc que es agnostico al lenguaje.

Empezado por ASAPLTDA

1.1 para exponer una función que existe en el servidor rest , que información debe proveer el servidor para que un cliente externo use la funcion ?

Si es algo interno nada, pero si quieres publicar una API pues debes hacer la documentacion adecuda.

Es popular por ejemplo, usar:

http://swagger.io/

----
La parte que reitero, ya que algunos piensas que REST es "usar json", es solamente la implementacion de los "VERBOS" http y de los URI. Se pueden pasar cualquier dato (incluyendo binarios) aunque es popular hoy usar Json, pero si hay razones para usar algo mas no hay que limitarse.

Por ejemplo, en mi caso yo paso tambien bases de datos sqlite (todo el archivo) y asi me ahorro un monton de trabajo, aparte que puedo hacer consultas sql identicas entre cliente y servidor.

Y usando la habilidad para abrir una BD sqlite dentro de otra, paso datos sin la sobrecarga de serializar/desearilizar, puedo usar transacciones y demas, Por ejemplo, en una app esto es parte de la sincronizacion (en Swift/ios junto a un servidor python):

Código PHP:

func downloadData(_ removeAbono:Bool) throws {
    Log.info("Downloading data...")
    
    let con = openDb()
    
    try con.inDatabase { db1 in
        try db1.execute("ATTACH DATABASE '\(syncpath)' AS 'sync'")
    }
    
    defer {
        con.inDatabase { db1 in try! db1.execute("DETACH sync")}
    }
    
    try con.inTransaction { db in
        
        try db.execute("DELETE FROM cliente WHERE version = 0")
        
        try db.execute("DELETE FROM Config")
        try db.execute("INSERT OR REPLACE INTO Config ( id, nombre, tipo, valor) SELECT id, nombre, tipo, valor FROM sync.Config")
        
        try db.execute("INSERT OR REPLACE INTO cliente ( cobro_id, codigo, direccion, fechaIngreso, id, nombre, orden, telefono, version, localid)  SELECT cobro_id, codigo, direccion, fechaIngreso, id, nombre, orden, telefono, version, localid FROM sync.cliente")                
        return .commit
    }
} 


Cientos de lineas de codigo ahorrada

Osea, REST puede ser un ideal, pero no hay que ignorar las posibilidades...