API frente a webhooks: ¿cuál es la diferencia?

Tanto las API como los webhooks permiten que diferentes sistemas de software sincronicen y compartan información. A medida que las aplicaciones de software están cada vez más interconectadas, es esencial que los desarrolladores comprendan la diferencia entre estas dos formas de compartir datos y seleccionen la herramienta que mejor se adapte a las necesidades de la tarea en cuestión.

¿Qué es una API?

Una API es como un portal a través del cual se puede compartir información y funcionalidad entre dos servicios de software. La palabra «interfaz» es clave para entender el propósito de una API. Al igual que un navegador web es una interfaz para que un usuario final humano reciba, envíe y actualice información en un servidor web, una API es una interfaz que proporciona programas de software con la misma funcionalidad.

Existen diferentes tipos y categorías de API (que analizaremos más adelante), pero en términos generales, las API son la forma más común de que los diferentes sistemas de software se conecten y compartan información. En la actualidad, Web programable proporciona una base de datos con más de 23 000 API que se ocupan de todo, desde datos epidemiológicos mundiales hasta bromas sobre papás. Cada API es un lienzo en blanco que espera a que los desarrolladores la vinculen a otras aplicaciones y la usen de formas nuevas y creativas.

¿Qué es un webhook?

Un webhook puede considerarse como un tipo de API que se basa en eventos en lugar de solicitudes. En lugar de que una aplicación solicite a otra que reciba una respuesta, un webhook es un servicio que permite a un programa enviar datos a otro tan pronto como se produce un evento en particular. Los webhooks a veces se denominan «API inversas», porque la comunicación la inicia la aplicación que envía los datos en lugar de la que los recibe. Dado que los servicios web están cada vez más interconectados, los webhooks se están convirtiendo en una solución ligera que permite notificaciones y actualizaciones de datos en tiempo real sin necesidad de desarrollar una API a gran escala.

Supongamos, por ejemplo, que quieres recibir notificaciones de Slack cuando se publiquen tuits que mencionen una cuenta determinada y contengan un hashtag específico. En lugar de que Slack pida continuamente a Twitter nuevas publicaciones que cumplan estos criterios, tiene mucho más sentido que Twitter envíe una notificación a Slack solo cuando se produzca este evento. Este es el propósito de un webhook: en lugar de tener que solicitar los datos repetidamente, la aplicación receptora puede sentarse y obtener lo que necesita sin tener que enviar solicitudes repetidas a otro sistema.

Las API permiten integraciones sólidas

Una característica importante de las API es que proporcionan una comunicación bidireccional entre diferentes programas de software a través de un ciclo de solicitud-respuesta, que normalmente utiliza Protocolo HTTP. En un caso de uso típico de una API, un programa de software solicitará un conjunto específico de datos a otro mediante una solicitud HTTP GET. Siempre que la solicitud sea válida, el sistema receptor responderá con los datos solicitados en un formato legible por máquina, normalmente XML o JSON. Esto es lo que permite a las aplicaciones compartir datos independientemente de sus lenguajes de programación individuales o de sus especificaciones internas. La naturaleza universal de las interacciones de la API puede permitir innumerables escenarios, desde que un usuario de iPhone compruebe la temperatura local a través del API AccuWeather a un conductor de Uber que se dirige a su próxima ubicación de recogida a través de la API de Google Maps.

Además de recibir datos, las API también pueden gestionar toda la gama de operaciones «CRUD» (crear, leer, actualizar y eliminar) entre dos aplicaciones. En otras palabras, las API no solo sirven para mostrar datos a un usuario en una interfaz, sino que también se pueden usar para modificarlos en la aplicación en la que están almacenados. Así es como las API permiten que los sistemas de software amplíen sus servicios y funcionalidades, y se integren con otras plataformas de una manera más completa y significativa.

La versatilidad de las API las convierte en herramientas poderosas para que los desarrolladores amplíen las capacidades de sus aplicaciones. La mayoría de los servicios web modernos incluyen API que permiten que sus datos y funciones se incorporen a otras herramientas; de hecho, sería raro encontrar un servicio web empresarial que no aproveche en cierta medida una API de al menos otra aplicación.

Los webhooks ofrecen un intercambio de datos ligero

Se podría pensar que, dado que los webhooks son eventos en tiempo real, son técnicamente difíciles de implementar. De hecho, una ventaja clave de los webhooks es que son más fáciles de configurar y consumen menos recursos que las API. La creación de una API es un proceso complejo que, en algunos casos, puede resultar tan difícil como diseñar y crear una aplicación en sí misma, pero la implementación de un webhook simplemente requiere configurar una única solicitud POST en el extremo remitente, establecer una URL en el extremo receptor para aceptar los datos y, a continuación, realizar alguna acción sobre los datos una vez recibidos.

Los casos de uso habituales de los webhooks incluyen el envío de nuevas suscripciones y cancelaciones de suscripciones a listas de correo electrónico a un sistema CRM, la actualización automática del software de contabilidad cuando se pagan las facturas o la configuración de cualquier tipo de notificación. En cada uno de estos tipos de eventos, la información fluye en una dirección y no es necesaria ninguna solicitud para recibir datos actualizados.

Las mismas características que hacen que los webhooks sean relativamente fáciles de implementar son también las razones por las que son mucho más limitados que las API. La actualización de los datos que entrega un webhook requiere reconfigurarlo por completo para detectar un evento diferente y, en la mayoría de los casos, sería más eficiente crear un nuevo webhook. Cuando dos sistemas comparten datos a través de una API con varios puntos finales, el sistema receptor tiene acceso a una gama mucho más amplia de datos del sistema emisor. Además, a diferencia de las API, los webhooks no permiten al sistema de envío añadir, actualizar y eliminar datos en el extremo receptor, por lo que los webhooks por sí solos son demasiado limitados para ofrecer una integración total entre dos aplicaciones.

Arquitectura de API: presente y futuro

Las API se clasifican en diferentes categorías según los protocolos y las arquitecturas que definen la forma en que envían y reciben datos. Históricamente, el patrón arquitectónico más común para el diseño de API ha sido REST, especialmente para aquellos que dan servicio a aplicaciones basadas en la web.

REST son las siglas de «Representational State Transfer». Este patrón, definido por Roy Fielding en 2000, permite que dos aplicaciones se comuniquen a través de HTTP de forma similar a los navegadores y servidores. REST no es un estándar oficial; más bien, es un conjunto de sugerencias sobre cómo diseñar APIs y otros servicios web. Una API se considera «RESTful» si su diseño sigue las siguientes recomendaciones:

• Cliente-servidor: Al igual que un navegador que solicita una página web a un servidor, en una API RESTful, la aplicación A realiza una solicitud a una URL alojada en la aplicación B a través de HTTP. La aplicación B luego evalúa la solicitud y devuelve los datos solicitados o un mensaje de error.
• apátrida: El sistema que responde no necesita saber nada sobre el estado de la aplicación del sistema que hace la solicitud para proporcionar una respuesta adecuada. La solicitud por sí sola debe contener toda la información necesaria para dar la respuesta.
• Capacidad de almacenamiento en caché: La respuesta debe indicar si el sistema receptor puede almacenarlo en caché o no.
• Sistemas estratificados: La API no depende de un sistema en particular para realizar la solicitud y entregar la respuesta. Esto significa que el sistema solicitante puede ser un cliente, un proxy o cualquier otro intermediario.

Así de simple ejemplo sigue las convenciones REST. Cuando visites la URL, tu navegador mostrará una actividad sugerida en la que participar si estás aburrido en formato JSON:

{
  "activity": "Go to a concert with some friends",
  "type": "social",
  "participants": 4,
  "price": 0.6,
  "link": "",
  "key": "4558850",
  "accessibility": 0.4
}

No importa cómo realices una solicitud a esta URL, ya sea con tu navegador, con RIZO, o una biblioteca cliente HTTP como buscar en JavaScript: la API devolverá el mismo objeto. Además de REST, otras convenciones de API incluyen JABÓN, COBRA y XML-RPC. Sin embargo, hasta la fecha, REST es el conjunto de directrices de arquitectura de API más utilizado.

En 2015, el equipo de ingeniería de Facebook publicó GraphQL—un nuevo lenguaje de consulta para las API destinado a proporcionar una alternativa más flexible al envío de solicitudes a los puntos finales de las API REST. Sin profundizar demasiado en las complejidades de GraphQL, la principal ventaja que ofrece sobre las API REST tradicionales es su capacidad de devolver los datos exactos que se necesitan con cada solicitud y, al mismo tiempo, evitar la «obtención excesiva» y la «búsqueda insuficiente», problemas que suelen surgir con las API tradicionales.

Por ejemplo, considere la siguiente situación. Una aplicación de reseñas de restaurantes debe mostrar los títulos de las reseñas más recientes que ha publicado un usuario, junto con las tres últimas personas que han seguido a ese usuario. Al usar una API REST, el cliente normalmente tendría que realizar tres solicitudes diferentes a diferentes puntos finales: una para obtener los datos iniciales del usuario, otra para devolver todas las reseñas de ese usuario y una tercera para devolver una lista de los seguidores de ese usuario. Con GraphQL, un cliente podría acceder a los mismos datos con una sola consulta: los requisitos exactos:

query {
    User(id: "qr3fsdcv24") {
        name
        posts {
            title
        }
        followers(last: 3) {
            name
        }
    }
}

Las API en funcionamiento en mParticle

Las API son el caballo de batalla del ecosistema técnico de mParticle. Son una gran parte de lo que permite a mParticle recopilar una visión omnicanal de sus clientes y compartir estos perfiles con herramientas de toda su cartera de marketing. Las más de 280 integraciones directas de mParticle con las principales soluciones de marketing, análisis y almacenamiento de datos se basan en API personalizadas con numerosas funciones que eliminan las complejidades de enviar datos en tiempo real y perfiles de usuario unificados a los sistemas posteriores.

En lugar de simples integraciones de webhooks, que se limitan a fuentes de datos unidireccionales, las integraciones de socios de mParticle se basan en API completas que permiten una interacción mucho más sólida entre los dos sistemas. Estas API siempre están muy activas entre bastidores, como cuando los clientes de mParticle dirigen sin problemas el flujo de sus datos en la interfaz de usuario de mParticle, por ejemplo.

La API de perfiles: consulta tus perfiles de usuario de mParticle directamente

Además de las API que impulsan las integraciones de los socios, mParticle proporciona a los desarrolladores de las empresas asociadas varias API para personalizar su recopilación de datos e individualizar mParticle según las necesidades específicas de su empresa.

Un ejemplo es la API Profile, que permite a los clientes recuperar mediante programación los perfiles de usuario creados mediante las capacidades de resolución de identidades y recopilación de datos multicanal de mParticle. Los datos recuperados al consultar esta API pueden ayudar a las marcas a crear rápidamente experiencias personalizadas dentro de los canales o entre ellos.

Este es un ejemplo de solicitud que podría enviarse a la API Profile para recuperar los datos de un perfil de usuario de mParticle:

curl \
  -X GET \
  -H "Authorization: Bearer <access token>" \
"https://api.mparticle.com/userprofile/v1/<orgId>/<accountId>/<workspaceId>/
<mpid>?fields=device_identities,user_identities,user_attributes,
audience_memberships,attribution"

He aquí un ejemplo de respuesta a esta solicitud:

{
   "mpid": 9080350317581165000,
   "created_timestamp_ms": 1574704283462,
   "last_stored_timestamp_ms": 1575301484215,
   "is_opted_out": false,
   "limit_ad_tracking": null,
   "device_identities": [
       {
           "type": "android_id",
           "encoding": "none",
           "value": "8789c459016a94b0"
       },
       {
           "type": "google_advertising_id",
           "encoding": "none",
           "value": "481c8a31-7d5d-4d96-93a0-2de7427167fc"
       }
   ],
   "user_identities": [
       {
           "type": "customer_id",
           "encoding": "none",
           "value": "Example-Customer-mxr15"
       },
       {
           "type": "email",
           "encoding": "none",
           "value": "Example-Customer-mxr15@example.com"
       }
   ],
   "account_userattributes": null,
   "user_attributes": {
       "view_preference": "Dark Mode",
       "tp_age": "18-34",
       "tp_gender": "male",
       "last_purchase_category": "Home Decor",
       "churn_risk_score": "4",
       "ltv": "342.1",
       "$city": "New York",
       "$state": "NY",
       "$country": "USA",
       "$firstname": "Marky",
       "$lastname": "Mark"
   },
   "audience_memberships": [
       {
           "audience_id": 17918,
           "audience_name": "Decor Remarketing",
           "expiration_timestamp_ms": null
       }
   ]
}

Para explorar esta API con más detalle, puedes experimentar con esta ejemplo de aplicación Node, que llama a la API mParticle Profile y devuelve el resultado a un cliente nativo.

Esperamos que esta publicación haya ampliado su comprensión de estos dos métodos comunes para compartir datos entre aplicaciones. La misma sabiduría que se aplica a todas las arquitecturas, marcos, patrones de diseño y tecnologías en la ingeniería de software también se aplica a las API y los webhooks: todo tiene su momento y lugar. La clave para aprovechar al máximo ambas herramientas es saber cuál es la adecuada para el trabajo.