Header Ads Widget

Ticker

6/recent/ticker-posts

API frente a webhooks: ¿en qué se diferencian?

 

Uno de los elementos más fundamentales, e importantes, del diseño de API es la elección del paradigma. Independientemente de la lógica empresarial o las necesidades situacionales de una API, comprender tanto por qué se elige un paradigma como por qué no se eligieron otros es fundamental para la construcción exitosa de cualquier sistema.

Hoy, veremos dos enfoques en el espacio de API: API web tradicionales y Webhooks. Tenga en cuenta que, si bien los Webhooks son técnicamente API, nos referiremos a las API en el sentido clásico (como veremos pronto).

¿Qué es una API?
Una API, o interfaz de programación de aplicaciones, es en su forma más básica un intermediario entre la información y aquellos que necesitan conocer la información. Si bien esto generalmente toma la forma de un intermediario entre dos aplicaciones o sistemas en un sentido local, cuando comenzamos a discutir los dispositivos en red, el cielo es el límite: una API puede facilitar todo, desde ejecutar la manipulación de datos basada en microservicios hasta el modelado 3D.

Lo que hace que una API sea diferente de un Webhook es cómo interactúa un usuario con ella. Normalmente, cuando nos referimos a una API, en realidad nos referimos a un tipo específico de API dentro de una colección de tipos mucho mayor. La diferencia entre un Webhook y una API es en gran medida una relación de "cuadrado y rectángulo"; todos los Webhooks son API, pero no todas las API son Webhooks. Lo que separa la concepción común de la API de los Webhooks es la naturaleza en la que se transfieren los datos al usuario.

En el sentido común de la API, los datos se entregan a pedido, como cuando un usuario realiza una acción, solicita un fragmento de datos o carga datos para procesarlos con una solicitud de salida. De esta manera, las API son extremadamente reactivas: reaccionan a la solicitud, pero generalmente no hacen nada por sí mismas sin que el usuario lo solicite.

¿Qué es un Webhook?
Los webhooks tienen muchos nombres, incluida API inversa o API push. Simplemente, los Webhooks son API que comparten información de forma proactiva en lugar de hacerlo de forma reactiva. Se crea un Webhook para monitorear la información y los sistemas de datos, rastreando los cambios de estado en el servicio. Cuando se detecta un cambio de estado, el Webhook "enviará" esta información a la persona que solicitó una actualización.

En esencia, este es un sistema proactivo, que responde a los eventos con un impulso reactivo. A diferencia de las API, los webhooks son reactivos, responden a la solicitud del usuario y envían esos datos solo cuando se solicitan. Esto puede parecer una simple inversión, pero es un cambio fundamental en el paradigma de la comunicación que hace de Webhooks una tecnología muy diferente para casos de uso muy diferentes.

API frente a webhooks
Una forma de pensar en las API y su relación con los Webhooks es considerar una analogía simple. Digamos que usted, el lector, quería pedir prestado un libro de la biblioteca. Cuando va a esta biblioteca, hay un conjunto de procedimientos y procesos que debe seguir para obtener este libro, uno de los cuales es el bibliotecario que verifica el stock del libro. En este punto, esto verifica si el libro está en stock, dónde está en el estante, o si no está en stock, cuándo será devuelto.

En el marco de una API, la información de stock es algo que debe crearse. Debe caminar hasta la biblioteca, pedir la información al bibliotecario y esperar a que toda esa información sea recopilada, cotejada, comparada y eventualmente entregada a usted. Una API en el sentido general funciona así: el usuario debe solicitar una gran cantidad de datos y esperar a que se sirvan.

El inconveniente aquí, por supuesto, es que debe ir constantemente a la biblioteca para verificar este stock, lo que desperdicia recursos (y puede ser muy frustrante). ¿No sería mejor obtener estos datos actualizados solo cuando los datos en sí están realmente actualizados? ¿No sería simplemente mejor si el bibliotecario hiciera un seguimiento de las existencias del libro, hiciera referencia al nombre que se dejó en un libro mayor y actualizara a esa persona cuando cambiara el estado del libro en la biblioteca?

Este es el concepto básico de Webhooks. En esta relación, puede decirle al sistema que le gustaría monitorear el cambio de estado y, cuando ocurra un cambio, que se le notifique y se vincule a él. Esto es mejor en determinadas situaciones, pero tiene sus pros y sus contras, sobre todo el hecho de que el flujo de información solo se produce en una única dirección. Sin más trabajo, realmente no puede responder a un Webhook puro con solicitudes adicionales de procesamiento.

Cuándo usar API y webhooks
La elección de utilizar o no una API de "extracción" clásica o un Webhook de "inserción" depende de cómo se pretende que fluyan los datos. Las API tienen un flujo de datos fundamental desde el usuario hasta la fuente. El usuario solicitará información de alguna forma, la API entregará los datos de alguna forma y la solicitud se cumplirá en un orden particular. Es ese orden el que determina la idoneidad de cada una de estas tecnologías.

Cuando se pretende que los datos fluyan desde un cambio de estado en la fuente hasta el usuario, un Webhook es lo más apropiado. Este proceso generalmente tomará la forma de una fuente que genera información o datos que provocan un cambio de estado, lo que desencadena un proceso definido para recopilar, cotejar y entregar estos datos. Si el usuario debe suscribirse primero o simplemente estar conectado al endpoint es una cuestión secundaria, ya que la faceta importante de este proceso es que el flujo debe ser desde la fuente y hacia el usuario.

Por otro lado, las API son mucho más apropiadas cuando los datos deben fluir del usuario a la fuente. Esto puede parecer confuso, después de todo, el usuario quiere los datos, no al revés, pero considere por un segundo qué datos está proporcionando el usuario. En una estructura API clásica, los datos iniciales enviados son la solicitud estructurada del usuario que detalla qué se solicita, desde dónde y en qué forma. Esto sirve como la primera fuente de datos en una cadena de datos que, en última instancia, hace que el usuario se retire del sistema. De esta forma, el usuario solicita y luego se actualiza.

Veamos dos ejemplos simples de dónde brilla cada tecnología. Digamos que tenemos un servicio que recopila audiolibros y los proporciona para un uso suscrito. El sistema subyacente es esencialmente una base de datos que une transmisiones de audio y cuentas de usuario, actuando como una especie de guardián. En este escenario, nuestro modelo de negocio determinará por completo qué tecnología adoptemos.

Si nuestro modelo es que, una vez al mes, un usuario recibe automáticamente un audiolibro específico dependiendo de sus gustos, tipos de suscripción, géneros u otros tipos de categorías de contenido, usaríamos un Webhook. En este caso, un Webhook puede aprovechar los datos de usuario existentes para determinar qué audiolibro querrá el usuario. Al detectar un cambio de estado (en este caso, el inicio de un "nuevo mes"), este contenido se entrega automáticamente al usuario como un envío de datos.

Digamos que queríamos que el usuario tuviera un mayor control sobre este servicio. En otro modelo, es posible que deseemos que nuestros usuarios puedan usar tokens digitales para elegir un libro de una lista de libros. Una API estándar es más apropiada en un modelo de este tipo, ya que necesitamos que el usuario realice una solicitud específica utilizando recursos específicos para obtener un libro. Esta relación de datos es pull, no push y, como tal, un Webhook no sería apropiado.

Es de destacar el hecho de que, en teoría, ambas tecnologías podrían existir al mismo tiempo. Quizás nuestros dos modelos de negocio podrían ser experiencias escalonadas diferentes. Por ejemplo, podríamos usar el modelo de Webhook para un "nivel de bajo costo", donde el usuario no tiene una opción ilimitada pero aún obtiene un libro seleccionado todos los meses, mientras sigue usando un modelo de API secundario para un "nivel premium". que el usuario puede utilizar después de recibir su libro mensual para "canjear" por un libro que deseaba. En este paradigma de diseño, básicamente tenemos dos procesos y modelos de negocio distintos que se apoyan entre sí y sirven a ambos lados de la moneda de “empujar y tirar”.

Conclusión
Tanto las API "clásicas" como los Webhooks representan situaciones comunes en la esfera del desarrollo web; ninguna solución es mejor. En cambio, ambas soluciones tienen su momento y lugar y, en algunos casos, incluso puede haber momentos y lugares en los que ambas sean apropiadas dentro del mismo sistema. Aprovechar el modelo adecuado permitirá una mayor experiencia y funcionalidad del usuario, así como un mayor control sobre el flujo de información para respaldar la lógica empresarial. En última instancia, el modelo más apropiado dependerá de varios factores, incluido el modelo comercial, la demanda del usuario y las necesidades fundamentales del consumidor.

Publicar un comentario

0 Comentarios