Las «interfaces de programación de aplicaciones» o más conocidas hoy como API surgieron en los primeros días de la informática. El término fue sugerido inicialmente en el artículo “Data structures and techniques for remote computer graphics” escrito por Ira W. Cotton publicado en 1968 y se puede resumir en la práctica como un puente entre dos ríos, es decir, una aplicación intermediaria a través de la cual durante dos software para comunicarse.
En este artículo, el autor informa con fascinación cómo funcionaría una API y su relativa ventaja, dada la idea hasta ahora defendida para los sistemas dedicados “El requisito es básicamente obtener una respuesta en tiempo real para el operador de la consola de visualización, al mismo tiempo que minimiza los gastos generales impuestos a las instalaciones informáticas centrales”. Pronto comenzaron a usarse como bibliotecas para sistemas operativos. En la década siguiente surgieron las redes informáticas y las nuevas arquitecturas informáticas que tenían como objetivo descentralizar el procesamiento y la comunicación entre mainframes, lo que dio lugar a la aparición de los primeros sistemas distribuidos.
En la década de los 80 vimos una popularización de los ordenadores personales, que fue acompañada por un aumento en la cantidad de aplicaciones desarrolladas, varios sistemas operativos y diferentes lenguajes de programación, complejizando la interconectividad entre aplicaciones. Y es que se comenzó a ver un auge en diferentes hardware, plataformas, software, protocolos y formatos de datos, buscando empresas informáticas para crear aplicaciones cada vez más escalables y flexibles.
Aunque la API enviaba mensajes entre mainframes, era predominantemente local. Hoy en día, las API se han expandido mucho más allá de los entornos locales y se han convertido en una tecnología importante para la integración remota de datos, ya que las redes de comunicación de datos se han consolidado sobre todo como un requisito económico y de marketing.
La API es un conjunto de definiciones y protocolos utilizados en el desarrollo e integración de software y aplicaciones, que permiten que tu producto o servicio se comunique con otros productos y servicios, sin necesariamente saber cómo se implementan, simplificando enormemente el desarrollo de aplicaciones y generando economías de escala, ya que reduce los costos de producción al tiempo que permite un aumento en los bienes y servicios. La expansión del uso de APIs trajo mayor flexibilidad al mercado, permitiendo una mejor administración y uso de herramientas, simplicidad en el diseño de nuevas soluciones y, como resultado, oportunidades únicas para producir innovaciones en el mercado.
La mejor definición de una API se encuentra en Carl Malamud (1990) quien la define como «un conjunto de servicios disponibles para un programador para realizar ciertas tareas».
En un principio, las API eran remotas, ya que estaban diseñadas para interactuar a través de redes de comunicaciones. Con la llegada de Internet hoy en día, este es el medio de comunicación preferido, razón por la cual la mayoría de las API están diseñadas en base a estándares web.
Un artículo interesante de redhat afirma que «No todas las API remotas son web, pero es justo decir que, en general, las API web son remotas».
Sin embargo, a diferencia de los servicios web, una API utiliza la comunicación asíncrona y se realiza principalmente a través del intercambio de mensajes intermediados por middlewares orientados a mensajes. La API ayuda así a comunicar su intención al sistema para que entienda y realice lo que se le ha solicitado.
Es un sistema perfecto para compartir información y recursos entre organizaciones, al tiempo que salvaguarda la seguridad, el control y la autenticación obligatoria, lo que le permite determinar a quién y a qué se puede acceder.
Por lo general, las API web utilizan el protocolo HTTPS para los mensajes de solicitud y proporcionan una definición de la estructura de los mensajes de respuesta. Actualmente, estos mensajes de respuesta tienen el formato de archivo XML o JSON, que son los más comunes en la actualidad. Tanto XML como JSON se destacaron con un amplio uso en el mercado porque presentan sus datos de forma simplificada, facilitando su uso por otras aplicaciones.
Las API se clasifican como privadas (solo permiten uso interno), asociaciones (se comparten con socios comerciales específicos para generar flujos de ingresos adicionales) o públicas (permiten que terceros desarrollen aplicaciones e interactúen con la API).
Con la expansión de las API web, se desarrolló una especificación de protocolo para ayudar a estandarizar el intercambio de información, que se denominó » Protocolo simple de acceso a objetos » – SOAP. Las API diseñadas con SOAP usan XML para el formato de sus mensajes y reciben solicitudes a través de HTTP o SMTP. SOAP se desarrolló para estandarizar solicitudes y formatos de mensajes, lo que facilitó que las aplicaciones que se ejecutan en diferentes entornos y con diferentes idiomas compartan información.
Otra especificación se llama «Transferencia de estado representacional» – REST. Mientras que SOAP es un protocolo, REST es un estilo de arquitectura y fue propuesto por Roy Thomas Fielding (2000), al escribir su tesis doctoral “Architectural Styles and the Design of Network-based Software Architectures” . Las API web que usan restricciones arquitectónicas REST se denominan API RESTful. Al no ser un protocolo, no existe un estándar oficial para las API web RESTful. Tal como lo define Fielding, las API son RESTful siempre que cumplan con las 5 restricciones rectoras de un sistema RESTful:
- Arquitectura cliente-servidor: En la arquitectura REST, la comunicación tiene lugar entre dos agentes en una red cliente-servidor. El cliente, a través de http, realiza solicitudes que deben ser respondidas por el servidor.
- Sin estado (stateless): No se almacena contenido del cliente en el servidor entre solicitudes. Una solicitud debe contener todos los parámetros necesarios para ser cumplida sin el almacenamiento de «memoria» del agente del servidor. La información del estado de la sesión se mantiene únicamente con el cliente.
- Almacenamiento en caché: el almacenamiento en caché puede eliminar la necesidad de algunas interacciones cliente-servidor, una estrategia que pueden implementar tanto el cliente como el servidor (almacenamiento en caché . Mejora el rendimiento general del sistema al disminuir el tiempo de respuesta de la aplicación.
- Sistema en capas (capas): las interacciones cliente-servidor pueden ser mediadas por capas adicionales (arquitectura de tubería y filtro). Estas capas pueden proporcionar funciones adicionales, como equilibrio de carga, cachés compartidos o seguridad, para mejorar el rendimiento del sistema.
- Interfaz uniforme: el intercambio de mensajes de cliente y servidor debe realizarse a través de interfaces uniformes o similares en su formato y modo. Esta restricción es un requisito esencial para el diseño de API RESTful e incluye 4 elementos de interfaz:
- Identificación de recursos: Los recursos se identifican en las solicitudes y se separan de las representaciones devueltas al cliente.
- Manipulación de recursos a través de representaciones: los clientes reciben archivos que representan recursos. Estas representaciones deberán contener información suficiente para permitir su modificación o supresión.
- Mensajes autodescriptivos: cada mensaje devuelto al cliente contiene información clara y suficiente para describir cómo el cliente debe procesar la información.
- Hipermedia como mecanismo de estado de la aplicación: después de acceder a un recurso, el cliente REST debería poder descubrir a través de hipervínculos todas las demás acciones disponibles actualmente.
Finalmente, el autor sugiere una sexta restricción que sería opcional. El “código bajo demanda”. En este caso, los servidores pueden ampliar la funcionalidad de un cliente descargando un código ejecutable. Es decir, la capacidad del servidor para «proporcionar» código para ejecutar en el cliente. La funcionalidad del cliente se puede insertar en tiempo de ejecución descargando y ejecutando código en forma de scripts.
Tanto el protocolo SOAP como la arquitectura REST permitieron una simplificación en el diseño de las APIs haciéndolas más útiles en la implementación, pero actualmente la arquitectura REST, también conocida como “arquitectura orientada a recursos” ha ganado cada día más credibilidad, gracias a su simplicidad inherente y la mejora del rendimiento de los sistemas que lo utilizan.
Las API son una excelente manera de hacer que un sistema no funcione aislado del resto del contenido que ya está disponible en Internet o incluso internamente dentro de una empresa. Son herramientas esenciales para que una organización se mantenga conectada e integrada.
Teniendo en cuenta eso, la versatilidad de las integraciones y las infinitas posibilidades de personalización de los bots están ahí, para que podamos aprovecharlas al máximo en nuestro negocio.
A continuación hay un enlace con 117 API para que construyas tu Chatbot: