BBVA Open4u - API First: el nexo de unión entre la web y el móvil

API First: el nexo de unión entre la web y el móvil

“La web está viviendo un punto de inflexión brutal. El modelo API First está ayudando a las compañía a asumir de forma más eficiente el desarrollo transversal entre móvil y web.”

BBVAOpen4U
|
21 Ene. 2016

Cada día suena con más fuerza y de forma más frecuente el concepto de “API First”. Ya no son sólo las pequeñas startups, sino las grandes compañías las que empiezan a adoptar esta estrategia. El motivo es claro: la web está viviendo un punto de inflexión brutal. La irrupción de nuevos dispositivos ha desplazado la idea original en la que se basan muchas empresas en internet. Dejan de ser una web para convertirse en una plataforma que tiene que estar presente en la mayor cantidad de dispositivos presentes: móvil, tabletas, TV y, por supuesto, en los navegadores de los ordenadores.

Aunque parezca una obviedad, la estrategia API First debe empezar con una idea clara en la cabeza: definir la API internamente antes que cualquier otro desarrollo. Ya sea ese proyecto una web o una app móvil, o ambas. Deben fijarse los recursos que van a ser utilizados previamente. Históricamente esto no ha sido así, la API era creada a posteriori para compartir e interactuar con webs ya creadas. Eso representaba situaciones complicadas al no haber sido optimizadas para tal uso, además de una importante carga de legacy code.

Errores comunes al crear una API ad hoc

Crear una API a posteriori tiene dramáticas consecuencias. Incurrimos en errores como exponer un modelo de datos o estructuras internas al resto del mundo, lo cual refleja tus propias restricciones y arquitectura.

Tan pronto como esté disponible a los desarrolladores (los consumidores de la API) se habrán acoplado a esa implementación. Al no definir una clara distinción entre API y arquitectura interna habremos perdido la flexibilidad de realizar cambios en nuestra aplicación interna sin afectar a los usuarios de nuestra API. Una API va más allá de exportar ciertos datos o interactuar con ellos. Representa una capa pública que protege nuestra implementación interna.

API First: la estrategia para unir la web y apps

API First encaja con el enfoque de la reutilización de reglas de negocio y de componentes de la plataforma, diferenciando la implementación interna y externa. A partir de esto web y móvil comparten una estrategia común, además de ir desarrollando de forma ágil las funcionalidades que incorpora nuestra aplicación. Nos vamos alejando del concepto primitivo de la exposición tal cual de datos hacia a un modelo único más centrado en la interacción.

API First debe abrir un flujo de comunicación común para la comunicación entre ambas partes:

●      Un lenguaje compartido a todos los niveles. No debe estar restringido solo a los desarrolladores, sino que los product managers, diseñadores y stakeholders deberán tomar decisiones sobre la definición de la API. Tanto el modelo de datos como las reglas de negocio se traducen en esa API e implica criterios de aceptación para cada una de las apps que se desarrollan en torno a esa API.

●      Delegación y responsabilidades: la API debe ser un facilitador, asume tensiones entre el componente técnico y de negocio. La definición del API debe reflejar esos compromisos. La parte común entre web y móvil va a estar delegada en la API.

●      Objetivo claro de uso. Juntando los anteriores puntos debemos definir el scope de uso y la aplicación práctica de dicha API proveer contenido e interacción a una app, servir de API externa para que desarrolladores la usen para sus propios mashups, etc…

●      Distinción entre la capa pública de la API y la externa. Debe incorporar mecanismos de seguridad y control de uso de los usuarios externos como OAuth o token.

Definición de una API: ¿cómo plasmarla?

El diseño previo de APIs requiere el uso de herramientas que tengan en cuenta la usabilidad, las necesidades de las aplicaciones/desarrolladores que vayan utilizarla, permitan realizar mocks testeables, posibiliten el versionado y, por supuesto, creen de forma conjunta al desarrollo de la documentación.

API Blueprint, RAML y Swagger representan tres excelentes herramientas para diseñar APIs, las cuales se están convirtiendo en estándares de facto. Con ellas podemos diseñar sobre el papel antes de su implementación la definición de la API en formato JSON o usando markdown para describir la interfaz, estructura y el modelo de datos.

Para interactuar con una API ya definida existen otras herramientas como Postman o PAW, las cuales generan un API Sandbox para interactuar con colecciones de API REST.

Más información sobre APIs aquí.

Síguenos en @CIBBVA

¡Suscríbete!

Recibe nuestro boletín semanal. No te pierdas nuestros trucos, consejos, artículos y los eventos más innovadores.