Tipos de APIs: Event-Driven

Tipos de APIs: Event-Driven

En el post anterior hablé de los tipos de APIs Request-Response. Ahora le toca el turno a las APIs event-driven.

En las APIs request-response, cuando cliente quiere tener el último estado de los datos tiene que pedirlos a la API. Si los quiere tener cada medio segundo, debería hacer una petición cada medio segundo. Esto conlleva un consumo de recursos enorme e innecesario si los datos no se modifican tan rápido.

Para solucionar este problema y tener datos en tiempo real, existen 3 mecanismos: WebHooks, WebSockets y HTTP Streaming.

WebHooks

Un WebHook es una URL que acepta un POST HTTP( o GET, PUT, o DELETE). Un API provider que implementa WebHooks simplemente hará un POST con un mensaje a la URL que se haya configurado. El funcionamiento es justo al revés que en APIs request-response. El provider es quien se comunica con el cliente para decirle que ha habido algún cambio en el servidor. De esta forma el cliente no tiene que preguntar al servidor cada X milisegundos si ha habido cambios en los datos, ahorrando así muchísimo tráfico de red. Parece sencillo implementar WebHooks en APIs existentes ya que únicamente tenemos que habilitar un nuevo endpoint que pueda aceptar requests como comenté anteriormente. Pero la realidad es que soportar WebHooks añade nuevas complejidades a nuestra API:

  • Errores y reintentos: para asegurar que los WebHooks funcionan correctamente, es importante implementar algún mecanismo que reintente la ejecución de ese WebHook en caso de que haya habido algún error.
  • Seguridad: aunque existen formas de hacer que las peticiones REST API sean seguras, la seguridad en WebHooks está actualmente en plena evolución. El estándar es que sea el cliente quien valide y asegure que un WebHook recibido es válido. Si no se hace de esta forma, puede que nuestra aplicación esté utilizando WebHooks no veríficados, y esto es muy peligroso porque nuestra API puede realizar acciones que no deseamos.
  • Firewalls: las aplicaciones que se ejecutan tras firewalls pueden acceder APIs a través de HTTP, pero no pueden recibir tráfico en el sentido contrario, es decir, de fuera a dentro. Para ese tipo de aplicaciones es difícil utilizar WebHooks y muchas veces imposible por políticas de empresa.
  • Ruido: normalmente, cada WebHook corresponde con un evento único. Pero, cuando hay miles de eventos en un periodo corto de tiempo, ese envío puede contener ruido, es decir, más de un evento por WebHook o ausencia de WebHook para un evento.

WebSockets

WebSocket es un protocolo utilizado para establecer una comunicación en streaming en 2 sentidos utilizando una única conexión TCP. Aunque normalmente este protocolo se utiliza entre un cliente web(browser) y un servidor, también es utilizado entre servidores.

Este protocolo está soportado por los navegadores más conocidos y es utilizado normalmente por aplicaciones en tiempo real(ej: chats).

Los WebSockets permiten la comunicación full-dúplex, es decir, el servidor y el cliente pueden comunicarse entre ellos de forma simultánea. Además, están diseñados para funcionar sobre los puertos 80 y 443, con lo que no habría problemas con firewalls

Los WebSockets son fantásticos para hacer conexiones de datos continuas, rápidas y que duren en el tiempo. Sin embargo, hay que tener cuidado si queremos utilizar WebSockets en conexiones móviles o en regiones con pérdidas intermitentes de conexión. Los clientes son los encargados de mantener la conexión viva. Si la conexión se pierde, el cliente debe reiniciarla. Además, hay ciertos problemas de los WebSockets en relación a la escalabilidad.

Streaming HTTP

En las APIs request-response, el cliente envía una petición y el servidor responde. Se acabó. Pero, también es posible dejar esa conexión abierta, o más bien, que la respuesta nunca termine. De esta forma, el servidor es capaz de enviar información en esa response siempre que lo necesite. Para esto hay 2 opciones:

  • En el servidor, fijar la cabecera "Transfer-Encoding = chunked". Esto le indica al cliente que los datos de respuesta llegarán en bloques separados por el carácter "nueva línea". De esta manera es sencillo para el cliente poder diferenciar los bloques de información.
  • Utilizar "eventos server-sent" (SSE). Esta es la mejor opción para clientes consumiendo la API a través de un navegador y así utilizar una la API de fuentes de datos estándar.

El streaming HTTP es fácil de consumir, pero uno de sus problemas más grandes es el buffering. Normalmente los clientes y proxies tienen un límite de buffer. Es decir, hasta que el buffer no esté lleno, no se transmite, con lo que el cliente no estaría 100% actualizado.

WebHooks WebSockets HTTP Streaming
Qué? Notificación de eventos HTTP Conexión en streaming en 2 sentidos sobre TCP Conexión de larga vida sobre HTTP
Ejemplo Slack, Stripe, GitHub, Zapier Slack, Trello, Blockchain Twitter, Facebook
Pros
  • Sencilla comunicación entre servidores
  • Utiliza el protocolo HTTP
  • Comunicación en streaming en 2 sentidos
  • Soporte nativo en navegadores
  • Puede atravesar firewalls
  • Streaming sobre HTTP
  • Soporte nativo en navegadores
  • Puede atravesar firewalls
Contras
  • No funciona a través de firewalls ni en navegadores
  • Gestionar errores, reintentos y seguridad es complejo
  • Es necesario mantener una conexión continua
  • No funciona sobre HTTP
  • La conexión bidireccional es compleja
  • La reconexión requiere recibir diferentes eventos
Cuándo usarlo? Para disparar eventos en tiempo real entre servidores Para conexiones en 2 sentidos y en tiempo real entre navegadores y servidores Para comunicaciones en un sentido de manera sencilla sobre HTTP