BBVA API Market
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.
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 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.
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
En el dinámico mundo de los pagos, ha surgido una nueva estrella en los últimos años: el Buy Now Pay Later (BNPL) es decir, la financiación a corto plazo que permite comprar ahora y pagar después. Este modelo permite a las empresas adquirir bienes o servicios y pagar por ellos en cuotas, a menudo sin […]
La forma a través de la cual se realiza el pago a los proveedores es un elemento a tener en cuenta dentro del departamento de tesorería y gestión de pagos, porque cada tipo de pago presenta sus propias ventajas o se adapta mejor a la estrategia de la empresa, la relación con el proveedor o […]
El leasing puede ser el impulso que necesitan las empresas para arrancar, abonando cuotas predecibles para usar bienes que, además, podrán adquirir luego descontando esos pagos. Las empresas, desde los autónomos hasta las grandes empresas pasando por las pymes, necesitan soluciones de financiación que se adapten a sus necesidades. El leasing es una fórmula que […]
