En el artículo anterior dedicado a analizar el panorama actual del mercado del desarrollo sugerimos que la web no es más que uno de los muchos medios donde un servicio debe estar presente. En la era de los dispositivos tenemos que procurar que nuestros usuarios obtengan una experiencia acorde al sistema que están usando.

Si tenemos el objetivo de ofrecer un servicio, debemos hacerlo lo más universal posible. No queremos hacerlo sólo para el colectivo de los usuarios de ordenador. Tampoco queremos decantarnos solo para los usuarios de sistemas iOS o Android, Windows, etc.

Es una faena tener que desarrollar lo mismo en diferentes lenguajes y plataformas, pero también es por eso por lo que nos pagan. Si nosotros fuéramos los gestores de una empresa tampoco querríamos cometer la estupidez de hacer una aplicación limitándonos solo para un segmento de todos nuestros usuarios potenciales. O al menos no deberíamos pensar así si queremos que un proyecto triunfe.

Ante este panorama ocurre que nuestro trabajo se multiplica, por cada uno de los tipos de plataforma a los que queremos dar soporte. Por ello es una excelente idea pensar de qué modo podemos reaprovechar la mayor parte del trabajo posible.

Un mismo Backend

Está claro que cada plataforma tiene un frontal específico, unas interfaces para comunicar entre el usuario y la máquina que se desarrollan en diferentes lenguajes. Esa parte por tanto no la podremos reaprovechar. En cambio, los datos de la aplicación, las reglas del negocio sí son las mismas entre todas las plataformas, por lo que son candidatos excelentes para su reaprovechamiento. Ahora bien, esta intención de disponer de un único backend nos obligará a cambiar algunas costumbres y la arquitectura de las aplicaciones.

Este marco es el ideal para entender la preocupación actual de desarrollo basado en API. Construir un backend, con datos y lógica de negocio que sea capaz de funcionar en cualquier frontal que queramos ponerle.

Para que nos entendamos. Antes, cuando se desarrollaba con un lenguaje del lado del servidor, lo que se conoce como desarrollo backend, nuestro lenguaje devolvía el HTML que queríamos que el navegador mostrase a los clientes. Hoy la tendencia cada vez más es construir un backend que devuelva datos en crudo, evitando generar HTML o cualquier otro tipo de salida específica de una plataforma.

El backend, cuando recibe una solicitud, suele responder enviando de vuelta datos en un lenguaje de intercambio, que podría ser el XML, aunque por su sencillez y ligereza de procesamiento los desarrolladores hemos acogido en masa JSON, la notación de objeto Javascript.

Ventajas del desarrollo basado en API

Desarrollar la parte del backend, la lógica del negocio en base a un API nos ofrece diferentes ventajas:

• Descargamos al servidor de la necesidad de renderizar código HTML, cuando generar un JSON es una tarea mucho más ligera. Dado que los servidores tienen que atender a muchos usuarios, cualquier cambio que implique descargarles de trabajo es siempre una buena alternativa.
• Damos más trabajo a los clientes web, que mediante Javascript son los responsables de generar la vista que se desee para mostrar esos datos. Como los ordenadores personales son cada vez más potentes y los navegadores más rápidos están encantados con esta nueva ocupación de renderizar HTML.
• La experiencia de usuario mejora, puesto que el servidor consigue completar antes su parte del trabajo, pero sobre todo porque los datos que viajan por la red son mucho más ligeros que si se mandan mezclados con el HTML.
• Si se desea mostrar los datos de otra manera, solo se tiene que cambiar el template Javascript que usamos. El backend se mantiene inalterado.
• Pero lo más destacado, para hacer las correspondientes App para cualquier plataforma de móviles, consumimos exactamente el mismo servicio backend, por lo que la mitad del trabajo de desarrollo ya está implementado cuando decidimos construir una app para una nueva plataforma. Reglas de negocio, seguridad, etc. se desarrollan una única vez en el backend y las usamos exactamente igual en cualquier plataforma.

Pero es que el desarrollo basado en API que devuelve JSON es cada vez más indicado para resolver problemas tradicionales de la informática de gestión. Hace unos meses hablaba con un desarrollador Java, profesor de una universidad de Madrid y le preguntaba acerca de las librerías para crear interfaces de usuario en Java, tipo Swing. Me decía que se estaban dejando de usar, que las empresas ahora demandan Java, pero principalmente para realizar la parte del backend, que el frontal ahora se desarrolla en web, dado que da más versatilidad, posibilidad de usarlo en cualquier entorno, localización, sistema, etc.

API REST

Hoy, la mayor apuesta para implementar un servicio web, base del desarrollo basado en API que hemos descrito anteriormente, se basa en lo que se conoce como API REST. REST es el acrónimo de "REpresentational State Transfer". Ni siquiera su traducción al castellano nos servirá para entender exactamente qué es REST. La clave en este caso es que un servicio REST no tiene estado. Una aplicación no guarda ninguna información de un usuario, entre una llamada al servicio web y la siguiente.

Esto, que pudiera parecer a priori un contratiempo (si pierdo el estado no soy capaz de saber qué usuarios están usando mi aplicación, en qué pantalla están, cuál es su identidad, etc.) en realidad se traduce en ventajas del lado del servidor y al final, en un mayor rendimiento.

Problemática de los datos de sesión

Los problemas de optimización de los sistemas backend suelen estar en el manejo de sesiones, que requiere un alto consumo de memoria, pues tienen que mantener datos de cada uno de los clientes. Imaginaros una aplicación como Facebook ¿cuántas personas pueden estar usándola a la vez? Pero no hace falta ir tan lejos, simplemente pensar en almacenar en memoria los datos de miles de usuarios.

Si piensas que con con aumentar la memoria del servidor será suficiente para atender a más usuarios, puede que tengas razón, pero hasta cierto límite. Hay un momento en el que, por mucho que aumentes la RAM del servidor no consigues un mayor rendimiento. Además, varios servidores menores en cluster suelen ser más eficientes que uno mayor. De hecho, replicar los servidores es la solución habitual cuando se necesita escalar una aplicación.

Pero en ese caso, de tener varios servidores, también los datos almacenados en la sesión son problemáticos. Si, para admitir más usuarios concurrentes se requiere hacer un balanceo de carga en un cluster de servidores, como los datos de la sesión deben estar en la memoria de una máquina, y no sabemos qué máquina será la siguiente en atender al mismo usuario, los datos de sesión pueden quedar en un lugar donde más tarde no se tiene acceso.

Entonces ¿Cómo se consigue mantener la identidad de una aplicación, cuando no somos capaces de mantener el estado de los clientes que nos visitan? cuando no conseguimos mantener ni siquiera una sesión abierta con los datos de autenticación del usuario que está consultando el servicio? La respuesta pasa por usar otro tipo de almacenamiento, como serían las bases de datos.

Sin embargo nuestro problema ahora estará en la autenticación. Si un usuario nos mandó sus credenciales para identificarse y debemos memorizar quién es a lo largo de toda la aplicación, nos veríamos en la necesidad de informar al servidor en cada solicitud acerca de su usuario y su clave. No podemos enviarlo de nuevo en todas las solicitudes, puesto que los datos de login generalmente no se guardan en la memoria del programa, así que tenemos que buscar otra solución. En este caso la tenemos en lo que se conoce como "Token".

Funcionamiento del token en API REST

Ahora vamos a resumir en pocas palabras lo que es el token, tan necesario para el desarrollo de aplicaciones basadas en API REST, que nos permitan tener un único backend para diferentes frontales.

El usuario, cuando se autentica en un servicio REST (porque las aplicaciones siguen necesitando autenticación y asegurarnos que los datos privados de los usuarios se mantengan únicamente accesibles para sus dueños), lo hará con sus credenciales de acceso, típicamente un usuario/mail y una clave. El servidor, una vez verificada la identidad, devuelve al cliente un token, que no es más que una cadena alfanumérica muy larga e irrepetible.

El token es único por tanto para cada usuario de la aplicación y tiene una caducidad corta. Cada solicitud que haga el mismo usuario al API REST vendrá acompañada del token de sesión y así el servidor sabrá que éste es el usuario que se ha autenticado, dueño de su información privada. El token, por supuesto el servidor no lo guarda en memoria, sino en un sistema de almacenamiento común que permita el acceso desde cualquier servidor, típicamente base de datos.