¿Qué es una API?

Por ejemplo, Twitter (ahora llamado X) tiene un sitio web donde podemos ver tweets. Al hacer clic en los enlaces, accedemos a distintas páginas: el feed de tweets, la página de un tweet específico, un perfil personal, la opción para restablecer la contraseña, el panel de publicidad, y más.

Cada una de estas páginas devuelve HTML, que muestra la información tal como la vemos, con todos los elementos de diseño. El sitio web de Twitter está adaptado para pantallas pequeñas y se puede abrir en cualquier dispositivo con un navegador. Pero además del sitio web, Twitter también tiene una aplicación móvil que muestra la misma información, pero con una interfaz más conveniente adaptada a un teléfono específico.

La aplicación móvil, a diferencia del sitio web, se almacena y se ejecuta directamente en el teléfono. Y todo el aspecto visual también se describe dentro de la aplicación. Para que esta aplicación funcione, necesita datos limpios que no están en el teléfono, sino en los servidores de Twitter. ¿Cómo se pueden cargar estos datos en el teléfono? Las direcciones normales de las páginas no nos sirven, ya que devuelven páginas HTML completas en lugar de datos.

Aquí es donde entra en juego la API. Twitter proporciona direcciones HTTP especiales que devuelven datos limpios en lugar de páginas web completas. Estos datos se devuelven en un formato estructurado, generalmente JSON. Un servicio "empaqueta" los datos en formato JSON, y otro servicio que los solicita los "desempaqueta" y los utiliza internamente para mostrarlos. Aquí hay un ejemplo de solicitud de un usuario:

El propósito de esta API es proporcionar un acceso conveniente a los datos de Twitter. Tanto Twitter mismo en sus aplicaciones móviles como otros servicios que administran Twitter utilizan esta API. Por ejemplo, los especialistas en marketing utilizan servicios que publican tweets automáticamente según un horario establecido.

Por cierto, Twitter utiliza su propia API, incluso para los widgets que se pueden incrustar en cualquier sitio web para mostrar tweets específicos o feeds de tweets. El navegador carga un código JavaScript que implementa la lógica de visualización y solicita datos al servidor (a través de la API).

Twitter tiene un sitio web especial para desarrolladores, donde se describe en detalle su API, las direcciones, los parámetros que se pueden pasar y los formatos de respuesta. Cualquier servicio con una API pública tiene una descripción similar, es decir, está disponible para su uso en Internet. Sin embargo, público no significa gratuito, ya que una API puede ser de pago y a menudo lo es.

La API de Twitter es un ejemplo de una API HTTP, que funciona a través del protocolo HTTP, que es el protocolo utilizado por los navegadores para cargar y mostrar sitios web. HTTP es el método más común y conveniente para crear API para servicios públicos en Internet. Es el protocolo en el que se basa todo Internet y tiene un buen soporte en cualquier lenguaje de programación. Después de todo, es un protocolo simple que todos los desarrolladores web conocen de alguna forma.

Sin embargo, no todas las API HTTP son iguales. HTTP deja muchas decisiones en manos de los desarrolladores, por lo que diferentes API HTTP pueden diferir significativamente, por ejemplo, en el formato de los datos. El formato más popular es JSON, pero también se utiliza XML. XML y HTML se parecen mucho en apariencia, pero XML describe datos en lugar de su apariencia y disposición:

Existen otros formatos, pero se utilizan mucho menos. En general, HTTP no limita el formato, se puede inventar y utilizar uno propio.

Además de los formatos, las API HTTP también difieren en cómo están estructuradas las direcciones. Por ejemplo, en code-basics, cada tipo de datos tiene su propia dirección:

Este tipo de API se conoce comúnmente como API REST. Se puede encontrar más información al respecto en otro artículo. A veces, una API se ve de tal manera que siempre tiene la misma dirección, pero se envían diferentes parámetros en la solicitud. Este enfoque tiene muchas variaciones, como json-rpc, graphql y otros:

Y finalmente, tenemos la API de Websocket, donde la interacción ocurre en tiempo real en ambas direcciones, a diferencia de los ejemplos anteriores, donde el cliente (quien usa la API) debe solicitar los datos. Con Websocket, se crean aplicaciones en tiempo real, como chats o juegos. En estas aplicaciones, los datos modificados en el servidor deben enviarse rápidamente a todos los clientes interesados.

Las API no se limitan solo a HTTP. Por lo general, este tipo de API se encuentra dentro de un servicio, para la interacción entre sus componentes, cada uno de los cuales se comporta como un pequeño servicio. Estas API pueden utilizar otros protocolos, como TCP, o construirse sobre otros enfoques, como colas de mensajes o flujos. Palabras clave: grpc, rabbitmq, kafka.