Para entender cómo funcionan servicios como IFTTT, Zapier o Flow hay que remontarse un par de años antes del 2.000 y al concepto de API.

APIs

En 1998 apareció una tecnología llamada SOAP (Simple Object Transfer Protocol) y basada en XML. Principalmente dotaba de interoperabilidad a páginas web ofreciendo a los desarrolladores un marco de desarrollo online llamado web API (Application Program Interface) o vademécum de los programadores, ya que explica cómo interactuar con una página web. Esto permitía habilitar canales de comunicación entre programas y los servicios web.

SOAP es una tecnología creada por Microsoft, que se estableció finalmente en 1999 como un primer estándar. No obstante, su aplicación no era demasiado trivial. Una de sus ventajas es que podía usarse en contextos más allá de la Web, pero su principal desventaja era el lenguaje XML. Esto convertía a SOAP en una tecnología rígida, estricta y que se complicaba según el lenguaje utilizado.

En el 2000 apareció otra aproximación llamada REST (Representational State Transfer) de manos de Roy T. Fielding y sus colegas. Su sencillez de uso hizo que ganara mucha expectación y muchos developers la adoptaran en sus soluciones. REST elimina el uso del rígido y estricto XML por la sencillez y flexibilidad del protocolo HTTP. El secreto de su sencillez radicaba en hacer llamadas a URIs mediante protocolo HTTP con verbos GET, PUT o  DELETE. Esto permitía una interoperabilidad más sencilla para interconectar aplicaciones con páginas, servidores entre servidores e incluso ahora aplicaciones en el Internet de las Cosas (IoT).

En el siguiente gráfico de Google Trends se ilustra la rápida adaptación de REST  API desde el 2004.

Servicios web en la nube

Un servicio web en la nube es una plataforma web que ofrece unas funcionalidades concretas. Por ejemplo comprobar cambios en un nombre de dominio, comprobar el SEO de una página web, avisar de enlaces rotos en un sitio web, ofrecer espacio virtual para guardar archivos o código (GitHub, Google Drive, Dropbox…), o gestionar los correos electrónicos de una cuenta corporativa o personal (GMail, Outloook…).

Todos esto servicios pueden ofrecer APIs para desarrolladores. El objetivo es que sus aplicaciones puedan conectarse a los servicios web, recuperar información e incluso alterarla. Esto permite crear soluciones alternativas e integraciones dentro de otras aplicaciones. Por ejemplo, se podría crear un Outlook alternativo con nuevas funcionalidades de automatización o un servicio de disco duro virtual que gestione archivos de distintos servicios como Dropbox, Box o Google Drive.

Automatización de servicios en la nube

Ahora más o menos ya te puedes hacer una idea de cómo funcionan los servicios de automatización en la nube como IFTTT o Zapier. Estos son plataformas web que interoperan con distintas APIs.

Cuando en IFTTT se crea un Applet que permite guardar un PDF en Google Drive cuando se recibe un correo GMail de un contacto en concreto se están utilizando dos APIs. Una para comprobar que en GMail se ha recibido un correo con PDF y otra para guardar el PDF en Google Drive. En la API de GMail solamente se consulta, pero en la API de Google Drive se está enviando información.

En Zapier pasa exactamente lo mismo. Para cada conexión con un servicio web se utiliza una API en concreto. Así que un Zapier con cuatro servicios utiliza como mínimo cuatro APIs, una para cada servicio utilizado.

La complejidad de estos servicios de automatización en la nube es mantener el sistema estable. Las APIs son entornos de programación mutables. Esto quiere decir que pueden existir distintas versiones, funcionalidades que se desestiman o configuraciones que desaparecen. Mantener el sistema estable, que todas las automatizaciones funcionen y seguir ofreciendo un servicio fiable, seguro e íntegro tiene una dificultad que solo servicios como IFTTT o Zapier pueden ofrecer.

Suscríbete a nuestra newsletter semanal