La insoportable levedad del REST

spring-657483_640

Después de la lectura de este artículo, me he quedado un poco sorprendido por la tesis que él se plantea. Tanto que no he podido evitar reseñarlo en el blog.

Dejando aparte que el autor  dice que las APIs REST le parecen desagradables, lo que es un poco subjetivo, vamos a recapitular por qué dice que esta forma de diseñar APIs es mala:

  1. Hay poco acuerdo en lo que significa REST.
    Mi opinión aquí es que no es así exactamente. Dejando aparte que como todo en esto siempre hay un punto de ambigüedad, creo que hay un consenso bastante generalizado de lo que es REST. Incluso creo que hay unas reglas muy sencillas para hacer un API REST (o al menos bastante REST).
  2. El vocabulario REST no está totalmente soportado.
    Esto puede ser así en los browsers como comenta, pero también podemos tener clientes REST que son aplicaciones, como las apps móviles, en los que se puede usar todo el vocabulario.
    En lo que respecta a usar el truco en los navegadores de mandar el verdadero verbo de HTTP (como DELETE) escondido en otro campo, digamos que no queda muy bonito, pero yo lo he usado y es práctico.
  3. El vocabulario no es lo suficientemente rico para las APIs.
    Está claro que no tiene todo el vocabulario, ni podemos expresar toda la semántica de un caso de negocio con los verbos de HTTP, pero yo diría que se aproxima bastante. En definitiva, creo que lo que perdemos en riqueza de vocabulario lo ganamos en sencillez.
  4. Son muy difíciles de depurar.
    Este punto no lo entiendo la verdad, ¿por qué dice que es difícil depurar? ¿Por que hay que saber la URI, el JSON, el código de retorno para poder invocarlo? no lo veo tan complicado.
  5. Están muy acopladas al HTTP.
    Esto es indiscutible, pero lo que hay que preguntarse es ¿Hay algún problema con esto? Me parece que no. El protocolo HTTP está por todos lados, es bien conocido y muy usado. Precisamente por eso es fiable y robusto.

En lugar de REST… JSON-Pure APIs

¿Y que es lo que propone para sustituir a REST?. Su propuesta es un concepto que denomina JSON-Pure APIs, que entre otras, tiene las siguientes características:

  1. Sólo usa un método de transmisión para mandar un request, normalmente un HTTP POST
  2. Separa completamente el contenido del mecanismo de transmisión
  3. Usa un sólo código de respuesta para confirmar la recepción del mensaje, normalmente HTTP Code 200
  4. Separa completamente la respuesta del mecanismo de transmisión.
  5. Es fácil de depurar porque toda la información está contenida en un mensaje JSON fácil de leer, con un vocabulario específico del dominio de negocio
  6. Puede ser fácilmente adaptado a diferentes canales de transmisión, como HTTP/S, Websockets, XMPP, etc.

Y digo yo, que si a todas estas características que propone para esta forma de diseñar APIs, sustituyes JSON por XML, tendremos a un viejo amigo… el SOAP. Precisamente el SOAP es independiente del protocolo de transmisión, usa sólo 200 o 500 como códigos de retorno, está autocontenido en el mensaje (estilo document), etc. etc. Todo eso está muy bien, pero si quieres todas estas características, ¿porque no usar SOAP y la pila WS-*en lugar de inventarse un nuevo estilo de diseñar las API?s.

Precisamente el éxito de las APIs tipo REST (uno de ellos) viene de su sencillez, su ligereza, su levedad… y de utilizar lo que viene de caja en el HTTP. No hace falta inventarse nada (cuanto más se invente más cuesta transmitirlo al resto del equipo y posibles usuarios del API). Todo ya está predefinido, ya se saben los verbos que hay, incluso los códigos de retorno. ¿Por otra parte, queda hoy en día algo que tenga chip y que no soporte le protocolo HTTP? Yo diría que no.

En definitiva, creo que no utilizaré el JSON-Pure APIs😉 ¿y tú?

Serverless, la nueva tendencia

less-is-more-791109_640

Hacía ya tiempo que no aparecería un nuevo concepto, un nuevo palabro, en el ámbito de la arquitectura T.I., del estilo de BaaS (Backend as a Service) o de Microservicios… pues bien, ya tenemos aquí uno: Serverless

Como en muchos de estos conceptos, el nombre no es muy afortunado, ya que si nos hablan de una aplicación del tipo serverless (sin servidor), lo primero que podemos pensar es que se trata de una app web o móvil que se ejecuta totalmente en el lado del cliente, en el dispositivo, y que obviamente, no tiene servidor. Pues bien, esto no es tan sencillo, ya que una aplicación de este tipo, si bien no tiene un servidor como el que estamos a acostumbrados a ver, sí que tiene una parte servidora en definitiva.

Concepto de Serverless

Este artículo del site de Martin Fowler ofrece una explicación del concepto y de sus orígenes, que básicamente se empezó a usar para definir a aquellas aplicaciones que dependen en servidor de terceras aplicaciones o servicios de terceros para manejar el estado y la lógica de negocio en el lado del servidor.

En lugar de tener una aplicación en el servidor, un conjunto de servicios, empaquetados en uno o varios artefactos (no tiene que por qué ser una aplicación monolítica). Un servidor de larga duración, es decir, pensado para arrancarlo y mantenerse vivo indefinidamente para responder a las peticiones de la parte cliente, tendremos otra “cosa”. Y esta cosa en realidad son varios servicios de terceros y algunas lógicas de negocio de vida efímera que sólo se “levantan” en respuesta a un evento y luego se vuelven a destruir… estaremos hablando de lo que se conoce como serverless.

sketch

En el ejemplo que se pone en el mencionado artículo tenemos una aplicación, que en la parte servidora, se compone de lo que llama “lógica de infraestructura” como un repositorio de autenticación que está manejado por terceras partes, en la nube, como por ejemplo un servicio de autenticación en Microsoft Azure. También se muestran bases de datos de sólo lectura que pueden estar en base de datos hosted en cloud….

Hasta este punto, yo no vi ningún problema en el planteamiento, pero la siguiente pregunta que cabe hacerse es “¿y qué pasa con la lógica de negocio de la aplicación?”. Para eso, sí que se necesita un servidor propio de la aplicación ¿no? ¿dónde está en un planteamiento serverless?

Pues bien, la respuesta a esta pregunta, es que se tienen lógicas de negocio o “funciones” propias de la aplicación en el servidor, pero no tenemos un servidor como tal… como podríamos imaginar un servidor Tomcat con una aplicación web Java en él…sino que  tendremos únicamente contenedores muy ligeros para esta lógica… una lógica como servicio o más bien “Function as a Service” (FaaS).

Un ejemplo de este contenedor de funciones o de lógicas de negocio es Amazon AWS Lambda que se describe precisamente como “ejecuta código sin pensar en servidores. Paga sólo por el tiempo que consumes”.

Captura de pantalla 2016-07-25 a las 17.06.40

Conclusión

En definitiva, Serverless es una vuelta más de tuerca al concepto de la nube y del “X as a service” llevado al extremo. Si en realidad sólo quiero ejecutar unas lógicas de negocio ¿para qué quiero gestionar un servidor?… dime dónde puedo “alojar” estas lógicas y se ejecutarán cuando se necesite, y cuando no las necesito, permanecerán “apagadas” y no me costarán un céntimo…. muy interesante.

 

 

Dominando la asincronía

clock-1392328_640

Llevo ya bastantes años programando, casi una eternidad, sobre todo en Java, pero también en php últimamente, y al principio, en la carrera, en todo tipo de lenguajes como C, Pascal, LISP, PROLOG, etc.

Hasta ahora me había encontrado con el uso de la asincronía muy de pasada, sobre todo cuando programé en java para el escritorio, con la librería Swing. Lo típico de crear un hilo nuevo para hacer un trabajo pesado y no detener el hilo de trabajo del primer plano para que el usuario no percibiera lags en la aplicación. Alguna llamada a un servicio asíncrono con un callback… en el servidor no se es muy amigo de crear hilos… en fin, ni de lejos nada con lo que he visto en los últimos días…

Renovarse o morir

Si amigos míos😉, he caído en el reverso tenebroso y me he puesto en serio a aprender node.js y de pasada el javascript… despúes del subidón inicial al comprobar que era capaz de hacer algún bot con el framework de Microsoft ha venido la gran depresión al encontrarme con un hecho que al principio parece anecdótico.. programar en node.js no tiene nada que ver respecto a hacerlo en aplicaciones Java de servidor. En java estamos a acostumbrados a que el servidor te asigne un hilo de ejecución (un thread) y en él puedes ejecutar el código que quieras de manera secuencial, todo muy “natural”, todo como siempre ha sido…

Sin embargo, node.js no es multihilo, sólo tiene un hilo de ejecución en realidad, pero casi todo lo que hace lo hace en modo asíncrono. Eso significa que cuando llamas a una función normalmente le pasas como parámetro otra función de callback para que te llamen una que se acaba el trabajo de la primera función… hasta ahí bien, pero que pasa cuando tienes que llamar a un servicio que te da una lista de elementos y después tienes que llamar a un servicio de detalle por cada elemento de la lista? pues que se desatan los infiernos… o como llaman los entendidos el callback hell.

Un ejemplo… ¿sencillo?

Para ilustrar un poco lo que quiero decir, os pondré el ejemplo de una prueba que hecho. La prueba consiste básicamente en llamar al API de Wunderlist (el gestor de tareas) para que liste las tareas que ya han alcanzado su fecha de fin.

Como en Wunderlist las tareas se agrupan en carpetas, lo que hay que hacer es obtener la lista de carpetas y luego en un bucle, para cada carpeta pedir sus tareas y ver si la fecha de fin es menor que la fecha actual. Desde el punto de vista de la programación secuencial tradicional ningún problema al respecto, únicamente hay que conocer el API de wunderlist y prácticamente ya está listo.

En cuanto se pasa a node.js, empiezan las cosas a complicarse, y mucho… se desatan los infiernos…. y es que como todo es asíncrono, la pedir el listado de carpetas, y empezar con la petición de las tareas, te encuentras que empieza una invocación cuando no ha acabado la anterior…. un desastre.

En la programación “tradicional”, se dispone de herramientas como la sincronización de métodos, los semáforos, etc. etc. para esperar a que un hilo acabe antes de continuar con la ejecución de otro… si embargo, la “manipulación” de hilos en el servidor no está permitida.

Al final, después de muchas pruebas, pensé en montar un sistema de pilas de trabajos, en la que se van apilando los “recursos” como las carpetas y las tareas según se vayan obteniendo y luego otro “hilo” que saca estos objetos de la pila y los trata. Cuando la pila se vacía, entonces todo el trabajo se ha acabado.

Este enfoque me parecía matar moscas a cañonazos para hacer algo tan simple como recuperar un listado de tareas de wunderlist… sin embargo, investigando un poco di con una librería de node.js que hacía precisamente esto, es esta async.

Captura de pantalla 2016-07-09 a las 10.24.39

En fin, como conclusión, tengo que decir que node.js me gusta mucho, a pesar de mis reticencias iniciales de programar en javascript (para un programador Java es poco menos que pasarse al lado oscuro😉 pero veo que tiene una gran potencia… y que es un lenguaje con futuro en el que se basan las “cosas nuevas” como los frameworks de desarrollo de bots. Así que no está nada mal salirse de la zona de confort y aprender no ya un nuevo lenguaje, si no una nueva plataforma y sobre todo una nueva forma de programar.

Buenas practicas en el desarrollo de servicios REST

Captura de pantalla 2016-06-05 a las 18.47.08

Siempre me ha gustado la documentación de WS2 (leído “güesos” para los amigos), el fabricante de Bus y API Gateway, en especial sus diagramas que encuentro tremendamente simples y autoexplicativos. Es por eso que no me he podido resistir a bajar su documento de buenas prácticas en servicios REST que puedes pedir aquí.

Antes de entrar en el contenido en sí del libro hay que recordar la definición de niveles de madurez de REST que puedes ver aquí, todo un must have que hay que tener cuenta cuando nos enfrentamos en el diseño de servicios REST. Esta clasificación del nivel de un API gateway nos ayuda a aprender el diseño del mismo y nos ayuda también a prevenir los errores más comunes en el diseño de servicios REST.

maturity

Sobre el documento de WS2, un poco largo, no todo es correcto a mi modo de ver. Me llama la atención la fijación que tienen sobre el data model, el que hay detrás del API. Y es que parece que consideran que el objetivo de todo API es acceder a un modelo de datos. ¿Dónde se quedó la orientación a objetos y la caja negra que todo servicio debe ser?. En mi opinión el modelo de datos es algo que debe permanecer oculto para el consumidor del API. Yo lo consideraría más bien como diagrama de clases.

Resource URIs

Especialmente importante es el apartado 5, sobre el diseño de las URIs de los recursos, que inexplicablemente parece que no se sigue demasiado.

{scheme}://{host}/{base-path}/{path}[?{query-string}]

Usa la barra “/” para indicar la relación jerárquica entre recursos. El nombre del padre debe preceder el nombre de sus hijos inmediatos.

El path base

/{feature-code}/[ {sub-code}/ ]/{version}

Propone la siguiente estructura para definir la base del path de la URI, agrupando los servicios por funcionalidad o feature. Dejando espacio también para una substructura (sub-code) si necesitamos hacer una subdivisión de los servicios por grupos de funcionalidad.

La versión del API es parte de su URI

Un documento útil y completo

También se trata el uso de los verbos de HTTP, las cabeceras de entrada y de respuesta y como no, lo que considero mi preferido, los códigos de status. ¿Por qué no se usan estos códigos en las APIs que veo en el día a día? es uno de esos misterios de la vida.

Temas como el filtro en las búsquedas, la paginación y el cacheo en la parte cliente también tienen cabida en este documento de buenas prácticas, sin olvidarse de la seguridad y de como reportar de errores.

Evidentemente no se puede estar al 100% de acuerdo con el documento pero casi. Una lectura muy recomendada si se quiere saber cómo diseñar servicios REST.

 

el ¿futuro? de los interfaces de los servicios

face to face

Llevo algún tiempo siguiendo de cerca el tema de los bots, esos programas que pueden conversar (más o menos) como un humano, normalmente mediante un chat, y que también son capaces de realizar acciones en plan mayordomo virtual, como comprar entradas de cine o encargar una pizza.

Claro que esto de los bots no es una cosa nueva, como casi todo. Ya llevan algunos años con nosotros. Un ejemplo famoso es el de Ikea en su página web… o el omnipresente Siri en el iPhone… o el Cortana en el windows… pero es ahora cuando en, plan the rise of the machines, se están poniendo de moda al juntarse la computación en la nube con el machine learning, haciendo posible teniendo un bot as a service en el que cualquier desarrollador, incluso de manera gratuita, puede desarrollar su propio bot para proporcionar un nuevo canal de negocio a su empresa. Pero yendo un poco más allá, y jugando un poco a T.I. ficción (o no tanto),

¿Que pasaría si la integración entre los servicios de dos empresas se hiciera mediante dos de estos bots, en lugar de los típicos servicios web a los que estamos acostumbrados?.

Quiero decir, por ejemplo, que si una empresa quisiera comprar un seguro a otra empresa, en lugar del típico servicio web de tarificar y contratar, con sus interfaces (sus contratos) definidos mediante un documento WSDL en el caso de un servicio SOAP, o de un swagger o similar en el caso de un servicio REST… ¿que pasaría si cada empresa dispusiese de un bot inteligente y que simplemente se pusieran hablar entre ellos como si de dos personas se tratase en una antigua plaza del mercado?. Este podría ser un diálogo:

– me interesa un seguro para un automóvil
– ¿que marca y modelo?
– Opel Astra 1.8i
– ¿quieres vehículo de sustitución?
– No
– …
– Son 340€. ¿Cómo los vas a pagar?

Evidentemente el lenguaje natural tiene muchos defectos para su tratamiento por un programa, principalmente su ambigüedad y su falta de concisión… Pero si nos ha servido a los humanos hasta ahora también podría valer a las máquinas. Además hay que tener en cuenta el aspecto inteligente y de acceso a la información de estos nuevos bots… Así por ejemplo, en una nueva hipotética conversación para comprar un nuevo seguro valdría con decir:

– quiero un nuevo seguro como el de antes pero para este otro modelo de automóvil…

La cosa cambia ¿no?

Ahora mismo puede parecer una absurdez tener este tipo de conversación entre dos programas, pero creo que es posible que nos encontremos con algo así dentro de no tanto tiempo.

En definitiva y aunque ahora nos parezca ciencia ficción no dejo de pensar que tal vez el futuro próximo que nos aguarda sea el de que los bots empresariales hablen unos con otros, con cientos o miles de conversaciones por segundo, con un conocimiento generalista, en el que no haya que predefinir previamente los interfaces de los servicios y que se puedan entender perfectamente… Al fin y al cabo son inteligentes ¿no?

Tan inteligentes que, como decía la revista Wired esta semana, estos entes de software ya no se programarán, simplemente se entrenará su inteligencia artificial…

Webinar: Diseño y construcción de un API Gateway

screwdrivers-1073515_640

El próximo jueves 12, a las 18.00 (11.00 en Perú), os convoco a todos a mi webinar “Diseño y construcción de un API Gateway” con los amigos de CAC-TI de Perú.

Cuando me puse a darle vueltas en un posible tema para este webinar, pensé en esta ocasión  por una visión más práctica  ¿Y qué mejor que contar los detalles del proyecto en el que llevo metido los últimos meses? Ni más ni menos que el diseño y construcción de un API Gateway sobre Google App Engine. Creo que es un tema que puede resultar interesante y en el que se puede mostrar la aplicación práctica de algunos de los conceptos y principios SOA que conocemos. Este API Gateway es sobre el que se basa el proyecto de Digital Meteo. Si quieres leer sobre este proyecto, puedes ver esta entrada en el blog: Machine Learning: el futuro ya está aquí.

API Gateway

Un API Gateway es básicamente un gestor de APIs, un sitio donde podemos publicar nuestras APIs para que otros desarrolladores las consuman de la forma más fácil posible, con tres grandes funcionalidades:

  1. Un módulo de runtime que maneja las peticiones que le llegan y las transforma y enruta al endpoint interno que servirá esta petición. Debe garantizar la seguridad y también controlar el consumo que hace el cliente.
  2. Una “tienda” a modo de autoservicio donde cualquiera pueda entrar, registrase y “comprar” la API que le interesa.
  3. Un portal de documentación con información sobre el API, modo de uso y también un sandbox donde se pueda probar.

Google App Engine

google app engine

La implementación del API Gateway está hecha sobre Google App Engine. Para el que no lo conozca, digamos que es una plataforma como servicio (PaaS) que proporciona al desarrollador todo lo que necesita para implementar y poner en producción su producto (servidor de aplicaciones, base de datos, caché, almacenamiento de ficheros, etc. etc.) y todo sin tener que preocuparse por instalaciones ni configuraciones. Desde el entorno de desarrollo a producción en minutos. 

En el webinar veremos una introducción a los conceptos de API y API Gateway, algunas consideraciones de diseño, la consola de administración de Google App Engine, el entorno de de desarrollo y algunos snippets de código java (procuraré que no muchos).

¿Quieres participar en el webinar? Muy fácil, regístrate aquí.

Servicios para bots

bot

Como diría el clásico, los bots están en efervescencia. En las últimas semanas tanto Facebook como Microsoft han subido a su CEO al escenario para contar que la gran novedad, lo más cool,  (con el permiso de la realidad virtual de Zuckemberg y las hololens de Natella) son los bots.

Para el que no esté familiarizado con el término, un bot es un programa (una aplicación si queremos verlo así) que utiliza el lenguaje conversacional para interactuar con el usuario. Normalmente, este bot se puede incluir como un contacto más en una conversación (hasta en un grupo de usuarios) y se le pueden pedir cosas (desde una pizza, que organice una reunión, que nos compre una entrada de cine o simplemente que nos entretenga con un chiste) sólo con pedirlo en lenguaje natural. Nada de comandos preestablecidos tipo “COMPRAR PIZZA + ingredientes”. Simplemente decirle al bot “quiero una pizza” y que él sepa cuáles son tus gustos y te envíe una a casa sin más.

Tal es el hype que se está viendo respecto a los bots que Microsoft ha definido la nueva interfaz de usuario como la interfaz conversacional. Parece que por fin estamos atisbando el fin del paradigma de IU basado en ratón (o dedo) con menús, ventanas y botones. Incluso hay gurús que planean el fin de la era de las apps, la de una app concreta para cada cosa, y la venida de la era de los bots que se “añaden” como hacemos con los amigos en Whatsapp. Incluso bots listísimos multipropósito, que valen para hacer de todo, como propone Facebook con su “M”… cada vez estamos más cerca de que cada uno tengamos nuestro J.A.R.V.I.S. particular como lo tiene Iron Men.

¿Qué se necesita para un bot?

Para que un bot sea considerado como tal tiene que hacer dos cosas (al menos):

  1. Que entienda el lenguaje natural (más o menos). Como lo hacen los asistentes de Apple o Microsoft (Siri y Cortana). Este lenguaje puede estar expresado por voz o texto.
  2. Que sea listo y que sepa que hacer una vez que ha entendido lo que quiere el usuario. De nada le sirve que entienda que quieres una pizza si luego no la puede encargar ¿no?. Para esto necesita, evidentemente, servicios de negocio.

Un tercer punto que hay que tener en cuenta es el “enlace” entre lo que ha entendido y los servicios que hay que invocar. Esto lo hace muy bien por ejemplo wit.io, la empresa que compró Facebook, y que ha definido un framework de construcción de bots.  La idea es sencilla, aunque su implementación es enormemente compleja: extraer de toda la parrafada que suelta el usuario en lenguaje natural a una intención de lo que quiere hacer, expresada como una etiqueta que un programador puede procesar fácilmente.

Captura de pantalla 2016-04-23 a las 9.58.08

Por ejemplo, si queremos fijar la temperatura de la habitación (como se ve en la imagen ianterior) y decimos “pon la temperatura de mi habitación a 25 grados”, el motor del bot es capaz de traducir esto a un intent que expresa de manera sencilla qué s lo que se quiere hacer “controlar la temperatura”, a esto se le añade lo que podríamos llamar parámetros que son en este caso la temperatura que queremos poner y dónde lo queremos hacer.

Para un programador es tremendamente fácil procesar esto, aunque sea con un if que compruebe este intent, abstrayéndole de la enorme complejidad de entender qué diablos está diciendo el usuario y traducirlo a una acción concreta, y por lo tanto, a qué servicio de negocio hay que llamar.

La conclusión creo que está clara: podemos considerar a los bots como un nuevo canal de interacción con el usuario/cliente. Un nuevo canal que va más allá de las webs y de las apps y que toca varios palos como son  el procesamiento de lenguaje natural, el machine learning y la inteligencia artificial y que en definitiva, necesitará servicios de negocio para poder proporcionar al usuario lo que necesita. Los bots son los nuevos consumidores de servicios SOA.