Continuamos con nuestro objetivo de construir una pequeña aplicación para ayudar al autónomo en su contabilidad que empezamos en el anterior articulo, y el paso de información para su gestor, vamos a ver como es una API, y tomar decisiones para construirla

En el articulo anterior, nos planteamos como podria ser una Base de datos que solucionará nuestros problemas, y nuestra primera decisión consiste en el motor a utilizar.

Habia pensado en utilizar la version gratuita de Oracle Express, pero, cuando fui a descargarla, me encontre con un producto que habia cambiado mucho desde la version que yo conocía y con la que había trabajado 4 años atrás, por lo que he decidido utilizar nuestro conocido MySQL ( o su clon MariaDB), que nos aparece ya instalado cuando montamos WAMP, XAMP o LAMP. Mas adelante, haremos la instalación de Oracle Express, y estudiaremos lo que nos cuesta cambiar toda la App de BBDD, y espero que sea muy poco.

Una vez aclarada nuestra apuesta por la base de datos, debemos ver como permitimos a nuestro usuario interaccionar con ella, en un entorno web.

La primera decisión es

  • Aplicación web o …
  • API

La principal diferencia entre las dos, está que , mientras que en una aplicación web, entregamos la salida perfectamente formateada para su visualización en un navegador, en la API, entregamos los datos, y ha de ser nuestro cliente el que organice su salida.

Supongo que ya habéis visto que con una API aparecen dos ventajas inmediatas,

  • Nuestro servidor se ahorra hacer las preparaciones de vista
  • los factores de accesibilidad y de usabilidad no sera responsabilidad nuestra
  • y la responsividad…tampoco

Si, hemos partido un problema en dos; la API se encarga de guardar la información y controlar todas las operaciones, mientras que la aplicación cliente se encarga de toda la interface externa, facilitando vistas o recibiendo datos.

Eso significa que el desarrollo de las dos partes, se puede realizar en paralelo, con el consiguiente ahorro de tiempo, y de la posibilidad de asignar equipos totalmente independientes, en donde solo tendremos que establecer los mensajes que se intercambiarán.

La filosofia API

Una aplicación API, la podríamos representar algo así

Y su paso a paso, podría ser:

  1. El cliente hace una petición, por medio de la URL
  2. El servidor decide que parte de la APP tiene que gestionar la petición
  3. Pasa, si es necesario por un sistema de autenticación para comprobar que el cliente está autorizado a realizar la petición
  4. Se invoca al módulo que la ha de realizar, y este utiliza un DAO si tiene que acceder a datos
  5. El Action Controller, formatea la respuesta (normalmente como un array de datos)
  6. Una última conversión prepara la salida para el viaje, convirtiéndola a XML,  a JSON, o a la forma de comunicación elegida

Dentro de la figura de puntos, he dejado cerrado lo que seria realmente nuestra aplicación, que debe recibir una URL y contestar con la información requerida, pero, realmente para poder funcionar requerimos mas pasos, aunque, quizás por su posibilidad de estandarizarlos, nos los podamos ahorrar.

El Framework Slim

Toda esa parte común del desarrollo, se la podemos confiar a un Framework, si, la hubiéramos podido programar, pero…ya está hecho, es sencillo y funciona bien…¿qué más queréis?

Hay varios framework que pueden realizar esa tarea, pero he decidido escoger uno muy sencillo, hace esto, lo hace bien y no me obliga a aprender demasiadas cosas… aunque algo si, y prometo dedicar un capítulo entero acerca de como utilizarlo, de momento, vamos a ver un poco su estructura

Basicamente, seria esta:

La petición atraviesa una serie de capas en donde se pueden realizar funciones, hasta llegar a la aplicación, y para salir, vuelve a atravesar las capas. por último, se convierte en el formato deseado, y se entrega

Se que esta explicación no es demasiado completa, pero creo que os permitirá haceros una idea bastante buena de en donde estamos trabajando.

En esas capas de «Midleware» podemos comprobar si el usuario está logonado, y si tiene permisos de acceso, o registrar cada acceso que hace, o guardar la información que se facilita

El sistema de ruteo de que dispone, llamara a la parte de la aplicación que queramos, organizando los datos para que nos sea más fácil manejarlos, y, cuando demos la respuesta, podremos indicar el status, o si queremos que lo convierta a JSON o no..,..

Otra ventaja que nos aporta Slim, es la facilidad de incorporar paquetes, y por ejemplo, eso lo notaremos en nuestro módulo de seguridad

El entorno de seguridad JWT

Como siempre simplificando, cuando debemos controlar la seguridad en un API nos encontramos con la necesidad de buscar una formula que garantice  , hasta donde se pueda, la inviolabilidad de la información.

Tambien debemos recordad que las normas mandan que una aplicación API debe funcionar sin el concepto de sesión, esto es, que no podemos guardar en el servidor absolutamente nada, entonces, ¿como podemos saber si el usuario esta autenticado?

La solucion que hemos adoptado, es la siguiente:

  1. El usuario hace una primera llamada, facilitando código de identificación y contraseña
  2. El sistema asigna un tokem y lo devuelve. Ese tokem puede estar limitado en el tiempo
  3. Todas las peticiones siguientes llegan con el tokem en el encabezado correspondiente, por lo que nos basta comprobar que ese tokem existe, y esta dentro de periodo de validez

Y nuevamente, podríamos realizar este pequeño módulo, pero nos encontramos con uno que funciona muy bien, e incluso te permite decidir el tamaño del tokem (128, 256, 1024, 2048…) con lo cual ¿para que hacerlo?, incorporaremos aquí JWT, le pediremos a Slim que se encargue de controlar el acceso, y listo.

Y algun detallito mas… que dejo para revisar en el proximo articulo, en el que espero empezar a codificar… PHP, nuestra primera opción para el servidor

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.