Header Ads Widget

Ticker

6/recent/ticker-posts

El presente y el futuro del diseño de API

 


La economía API está creciendo. Las API ya no son un juguete o un truco para que las empresas presuman. Son recursos comerciales completos y, a menudo, productos en sí mismos.

Como dice James Higginbotham en la introducción de su libro A Practical Guide to API Design , coescrito con el Dr. Keith Casey Jr. , "Si lees la prensa técnica, probablemente tengas la sensación de que todos saben que necesitan una API, aunque la mayoría no está realmente segura de qué es. Tratan a las API como otra casilla de verificación, como lo era "Web 2.0" hace unos años o como lo eran recientemente las aplicaciones móviles ".

Teniendo en cuenta la cantidad de datos que los usuarios procesan a diario, se podría argumentar que las API son esenciales para el éxito empresarial. medida que continuamos avanzando hacia una sociedad basada en datos. Eso significa no solo comprender el estado actual del diseño de API, sino también hacia dónde nos dirigimos en la industria.

Este artículo está inspirado en la presentación de James Higginbotham de la Cumbre de API de Austin 2019, "API, microservicios, sin servidor: la forma de las cosas por venir". Higginbotham es el fundador de LaunchAny , una empresa de consultoría de API. Con casi 15 años creando API para una amplia variedad de industrias, está calificado de manera única para comprender hacia dónde se dirige la industria de las API.

API, microservicios, sin servidor: la forma de lo que vendrá

La presentación de James Higginbotham de la Austin API Summit cubrió la realidad actual de la industria API. Necesitamos entender el estado actual de la economía de las API si queremos entender hacia dónde se dirige.

El panorama de las API

Higginbotham lidera con una cita de Roy Fielding, el creador del lenguaje REST .

“La interfaz de descanso está diseñada para ser eficiente para la transferencia de datos hipermedia de gran tamaño, optimizándose para el caso común de la Web, pero dando como resultado una interfaz que no es óptima para otras formas de interacción arquitectónica”. - Roy Fielding

¿Qué quieren decir exactamente Higginbotham y Fielding con comunicación “de grano grueso” frente a comunicación “de grano fino”?

De grano grueso vs. Comunicación detallada

Como cubrimos en el blog, la granularidad es cómo un sistema se divide en componentes más pequeños. La comunicación de grano grueso tiene un número menor de componentes más grandes. La comunicación de grano fino divide esas piezas en trozos más pequeños y digeribles.

Por ejemplo, un módulo de comunicación de grano grueso podría etiquetarse como "Cuentas". Esto almacenaría el nombre del cliente, la dirección, la fecha de apertura, el saldo de la cuenta y la fecha del último cambio. Esas subdivisiones serían ejemplos de comunicación detallada .

La comunicación de grano grueso puede ser grande, difícil de manejar y difícil de implementar. La comunicación de grano fino ofrece la capacidad de clasificar los datos a un nivel más útil y utilizable. Esto será cada vez más importante a medida que nos acerquemos a una economía verdaderamente basada en datos .

También es un ejemplo de cómo el futuro del diseño de API implicará integración y colaboración en lugar de operar en el vacío.

El viaje de la plataforma API empresarial

APIS, microservicios, sin servidor: el estado de las cosas por venir ilustra muchos de estos principios utilizando una plataforma de comercio electrónico ficticia como ejemplo.

La mayoría de las API de nivel empresarial comienzan siendo bastante simples. A menudo, las empresas buscan desarrollar una aplicación web o móvil. Pueden crear una única API para alimentar sus aplicaciones. Estas aplicaciones comienzan a tener algo de tracción en el mercado, lo que las lleva a contratar más desarrolladores, lo que ralentiza el proceso de desarrollo.

En este punto, las empresas suelen comenzar a incorporar microservicios . Los microservicios son una forma de reducir la coordinación, al dividir las cosas en servicios más pequeños y más implementables como parte de una arquitectura más grande.

Higginbotham se centra en la interfaz y las dependencias que rodean a los microservicios.

Las interfaces incluyen:

  • Consultas
  • Comandos
  • Eventos publicados

Las dependencias se componen de:

  • Dependencias de servicios
  • Suscripciones a eventos

Pensar en esta línea ayuda a los desarrolladores a salir del patrón CRUD (Crear, Leer, Actualizar, Eliminar), lo que permite a otros desarrolladores hacer uso de la API de manera más rápida y efectiva.

Sin servidor: desarrollo rápido de API y procesamiento de eventos

Serverless es una tendencia reciente en el desarrollo de API que permite que las API sean lo más eficientes posible. Higginbotham ofrece el ejemplo de Acciones de GitHub  para demostrar cómo los equipos no necesitan alojar sus propias funciones, sino que se pueden automatizar muchas cosas desde un solo empuje de Git.

Luego detalla cómo se podría diseñar y construir una API en un entorno empresarial . Una vez que todo funciona sin problemas, el C-suite a menudo quiere que la API se convierta en comercializable , con la capacidad de realizar ventas adicionales y cruzadas de los servicios. Esto trabaja con el objetivo de aumentar el monto de venta de cada transacción a través del sitio web.

Esto requiere profundizar en los datos a un nivel más granular, lo que permite obtener más información procesable en la API. En esta etapa, la cuestión de la gestión de datos y los permisos se vuelve más importante y las canalizaciones de datos empiezan a entrar en juego. Higginbotham detalla dos tipos de canalizaciones de datos.

ETL

ETL significa "Extraer, transformar, cargar". ETL se vuelve cada vez más difícil de implementar a medida que los datos se vuelven más complejos.

ELQT

ELQT significa "Extraer, Cargar, Consultar, Transformar". A medida que las demandas de datos se vuelven más grandes y urgentes, se hace necesaria la transmisión de datos a alta velocidad. La transmisión de datos podría provenir de servicios como Kafka, Pulsar, Kinesis u otros.

Esto lleva los datos a un lago de datos donde nunca se vuelve a ver. O puede emplear plataformas de visualización de datos como Apache Spark, que permite a los desarrolladores consultar y transformar datos, haciendo que la visualización y el análisis de datos sea más posible.

Una vez que las API llegan al mercado, comienzan a surgir problemas.

La plataforma API en evolución

Higginbotham recomienda comenzar con lo que está tratando de lograr y luego concentrarse en la API. Desglosa la forma más fácil de evaluar las API en dos componentes: capacidades y operaciones .

La forma más sencilla de evaluar las capacidades de la API se conoce como semántica pragmática a nivel de aplicación (ALPS).

¿Qué es ALPS? Una descripción general

ALPS es un formato independiente del protocolo para representar las capacidades de una API y los campos de valores centrales involucrados en el uso de esa capacidad. Se convierte en una definición de interfaz para API.

Esto permite a los desarrolladores un marco para evaluar las capacidades de la API y luego definir esas capacidades en un formato legible por máquina, lo que permite que la API interactúe con otros entornos, como OpenAPI, o servidores, utilizando HTTP.

El viaje hacia una plataforma API empresarial

El viaje de la API empresarial continúa evolucionando. Inicialmente, una empresa puede pensar en las cosas solo como una serie de API internas para ayudar a automatizar las funciones internas. Las cosas se vuelven más complejas a medida que más desarrolladores comienzan a usar las API. Se vuelven aún más complejos cuando se integra una capa de flujos de datos y análisis. Higginbotham postula que debemos pensar más allá de la interfaz REST básica para manejar todas estas capas adicionales.

Funciona como una solución (FaaS)

Una forma de atravesar capas complejas es mediante la adopción de Funciones como solución (FaaS). FaaS ofrece la posibilidad de que las API se conecten con otros sistemas, lo que permite a los desarrolladores crear rápidamente nuevos productos y lanzarlos al mercado.

Las posibilidades son casi infinitas cuando se combinan con los aspectos sin servidor de Platforms as a Service (PaaS). Solo tiene que escribir un código de implementación y rápidamente puede tener un nuevo producto funcionando 24/7.

El futuro de las API

“Nos estamos moviendo hacia un mundo nuevo donde los usuarios ya no recurren a las aplicaciones para hacer las cosas”, afirma Higginbotham. "En lugar de que los usuarios recurran a las aplicaciones, las aplicaciones están llegando a los usuarios".

Las plataformas de mensajería y colaboración son especialmente indicativas de esta progresión. En estos entornos, en lugar de enviar un correo electrónico diciéndole a alguien que abra una aplicación en particular, ciertos eventos pueden  desencadenar un proceso en particular.

Higginbotham está lleno de sabios consejos sobre el estado actual del diseño de API. Nos deja algunas ideas más:

  • Escalabilidad : los procesos de API actuales pueden no ser escalables. En lugar de crear e implementar API constantemente, Higginbotham aboga por un retorno a los formatos cliente-servidor como los viejos tiempos de Visual Basic.
  • En los mercados : nuestros mercados se mueven incluso más rápido que en los años 90, cuando reinaban las soluciones cliente-servidor.
  • El código bajo vuelve a estar de moda : las soluciones Low-Code / NoCode van a ser incluso más importantes de lo que eran en los años 90. Cosas como Node-Red permiten a JavaScript ejecutar soluciones de IoT y unir API . Soluciones como Zapier o ifttt.com hacen posible la automatización sin escribir una sola línea de código.
  • El análisis de datos es importante para la economía basada en datos : programas como Apache Airflow permiten a los desarrolladores ejecutar análisis de datos dentro de una tubería de datos y diseñar gráficos acrílicos dirigidos (DAG) para procesar datos tanto en paralelo como en serie.
  • Marcos para la integración : finalmente, existen lenguajes como Ballerina para escribir microservicios que permiten que las API se comuniquen e integren. La integración de las API será cada vez más importante en el futuro de las API.

Publicar un comentario

0 Comentarios