¿Qué son las API?
Una interfaz de programación de aplicaciones (API) es un conjunto de herramientas, definiciones y protocolos que se usa para diseñar e integrar software de aplicaciones. Permite que su producto o servicio se comunique con otros productos y servicios, sin la necesidad de saber cómo se implementan. Las API simplifican el desarrollo de las aplicaciones, lo cual permite ahorrar tiempo a los desarrolladores y dinero a las empresas. Cuando diseña herramientas y productos nuevos (o maneja otros actuales), las API le otorgan flexibilidad; simplifican el diseño, la administración y el uso; y proporcionan oportunidades para la innovación.
Debido a que simplifican la forma en que los desarrolladores integran los elementos de las aplicaciones nuevas en una arquitectura actual, las API permiten la colaboración entre los equipos de TI y de negocios. Las necesidades comerciales suelen cambiar rápidamente en respuesta a los mercados digitales en constante cambio, donde la competencia puede modificar un sector entero con una aplicación nueva. Para seguir siendo competitivos, es importante admitir la implementación y el desarrollo rápidos de servicios innovadores. El desarrollo de aplicaciones nativas de la nube es una forma identificable de aumentar la velocidad de desarrollo y se basa en la conexión de una arquitectura de aplicaciones de microservicios a través de las API.
Las API son un medio simplificado para conectar su propia infraestructura a través del desarrollo de aplicaciones nativas de la nube, pero también le permiten compartir sus datos con clientes y otros usuarios externos. Las API públicas representan un valor comercial único porque simplifican y amplían la forma en que se conecta con sus partners y, además, pueden rentabilizar sus datos (un ejemplo conocido es la API de Google Maps).
Por ejemplo, imagine una empresa distribuidora de libros. La distribuidora de libros podría dar a sus clientes una aplicación que les permita a los empleados de la librería verificar la disponibilidad de los libros con el distribuidor. El desarrollo de esta aplicación podría ser costoso, estar limitado por la plataforma y requerir mucho tiempo de desarrollo y mantenimiento continuo.
De forma opcional, la distribuidora de libros podría proporcionar una API para verificar la disponibilidad en inventario. Existen varios beneficios para este enfoque:
- Permitir a los clientes el acceso a los datos con una API que les ayude a añadir información sobre su inventario en un solo lugar.
- La distribuidora de libros podría realizar cambios en sus sistemas internos sin impactar en los clientes, siempre que el comportamiento de la API no cambie.
- Con una API disponible de forma pública, los desarrolladores que trabajan para la distribuidora de libros, vendedores o terceros podrían desarrollar una aplicación para ayudar a los clientes a encontrar los libros que buscan. Esto podría dar como resultado mayores ventas u otras oportunidades comerciales.
En resumen, las API le permiten habilitar el acceso a sus recursos y, al mismo tiempo, mantener la seguridad y el control. Cómo habilitar el acceso y a quiénes depende de usted. La seguridad de las API tiene que ver con una buena gestión de ellas. Para conectarse a las API y crear aplicaciones que utilicen los datos o las funciones que estas ofrecen, se puede utilizar una plataforma de integración distribuida que conecte todos los elementos, incluidos los sistemas heredados y el Internet de las cosas (IoT).
Innovar con las API
Exponer sus API a partners o al público permite:
- Crear nuevos canales de ingresos o ampliar los existentes. Por ejemplo, API Map Google y API de Geo-location.
- Expandir el alcance de su marca.
- Facilitar la innovación abierta o lograr mayor eficiencia mediante el desarrollo y la colaboración externos.
¿Suena genial, no? ¿Pero cómo pueden las API hacer todo esto?
Volvamos al ejemplo de la empresa distribuidora de libros.
Supongamos que uno de los partners de la empresa desarrolla una aplicación que ayuda a las personas a encontrar libros en los estantes de la librería. Esta experiencia mejorada atrae más compradores a la librería (que es cliente de la distribuidora) y expande un canal de ingresos existente.
Es posible que un tercero use una API pública para desarrollar una aplicación que permita a las personas comprar libros directamente de la distribuidora, en lugar de hacerlo en una tienda. Esto abre un nuevo canal de ingresos para la distribuidora de libros.
Las API compartidas, con partners elegidos o con todo el mundo, tienen efectos positivos. Cada asociación amplía el reconocimiento de su marca más allá de los esfuerzos de marketing de la empresa. Habilitar la tecnología a todo el mundo, como con una API pública, alienta a los desarrolladores a crear un ecosistema de aplicaciones en torno a su API. Si hay más personas que usan su tecnología, esto significa que hay más personas dispuestas a hacer negocios con usted.
Hacer pública a la tecnología conduce a resultados novedosos e inesperados. Estos resultados, a veces, alteran sectores completos. Para nuestra empresa distribuidora de libros, las nuevas firmas (un servicio de préstamo de libros, por ejemplo) pueden cambiar la manera en que se comercializa. Los partners y las API públicas le permiten aprovechar los esfuerzos creativos de una comunidad más grande que su equipo de desarrolladores internos. Las nuevas ideas surgen de todas partes, y las empresas deben ser conscientes de los cambios en su mercado y estar listas para actuar en consecuencia. Las API pueden ayudar.
Una historia extraordinariamente resumida de las API
Las API emergieron en los primeros días de la informática, mucho antes que la computadora personal. En ese momento, una API se usaba normalmente como una biblioteca para los sistemas operativos. Las API casi siempre fueron locales para los sistemas en los que operaban, aunque, a veces, pasaban mensajes entre las computadoras centrales. Después de casi 30 años, las API se expandieron más allá de los entornos locales. A principios del año 2000, ya eran una tecnología importante para la integración remota de datos.
Las API remotas
Las API remotas están diseñadas para interactuar a través de una red de comunicaciones. Por “remoto” nos referimos a que los recursos que son administrados por las API están, de alguna manera, fuera de la computadora que hace el requerimiento. Debido a que la red de comunicaciones más usada es Internet, la mayoría de las API están diseñadas según estándares web. No todas las API remotas son API web, pero es justo asumir que las API web son remotas.
Las API web, normalmente, usan HTTP para solicitar mensajes y proporcionar una definición de la estructura de los mensajes de respuesta. Estos mensajes de respuesta, por lo general, toman la forma de un archivo XML o JSON. Tanto XML como JSON son los formatos preferidos porque presentan datos de manera que son fáciles de manejar para otras aplicaciones.
¿Qué se ha hecho para mejorar las API?
A medida que las API se han desarrollado en las ahora generalizadas API web, se han realizado muchos esfuerzos para simplificar su diseño y facilitar su implementación.
Un poco de SOAP, mucho de REST
A medida que las API se han difundido, se desarrolló una especificación de protocolo para permitir la estandarización del intercambio de información: Protocolo de Acceso a Objetos Simples, más conocido como 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 facilita la ejecución de las aplicaciones en entornos diferentes o escritas en diferentes lenguajes para compartir información.
Otra especificación es la Transferencia de Estado Representacional (REST). Las API web que adhieren a las limitaciones de arquitectura REST se llaman API de RESTful. La diferencia entre REST y SOAP es básica: SOAP es un protocolo, mientras que REST es un estilo de arquitectura. Esto significa que no hay un estándar oficial para las API web de RESTful. Tal como se define en la disertación de Roy Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, las API son RESTful siempre que cumplan con las 6 limitaciones guía de un sistema RESTful:
- Arquitectura cliente-servidor: la arquitectura REST está compuesta por clientes, servidores y recursos, y administra las solicitudes a través de HTTP.
- Sin estado: ningún contenido de cliente se almacena en el servidor entre requerimientos. En su lugar, la información sobre el estado de la sesión está en posesión del cliente.
- Capacidad de caché: el almacenamiento en caché puede eliminar la necesidad de algunas interacciones cliente-servidor.
- Sistema en capas: las interacciones cliente-servidor pueden estar mediadas por capas adicionales. Estas capas pueden ofrecer funcionalidades adicionales, como equilibrio de carga, cachés compartidos o seguridad.
- Código de demanda (opcional): los servidores pueden extender la funcionalidad de un cliente transfiriendo código ejecutable.
- Interfaz uniforme: esta limitación es fundamental para el diseño de las API de RESTful e incluye 4 aspectos:
- Identificación de recursos en requerimientos: los recursos se identifican en los requerimientos y se separan de las representaciones devueltas al cliente.
- Administración de recursos mediante representaciones: los clientes reciben archivos que representan recursos. Estas representaciones deben tener la información suficiente como para poder ser modificadas o eliminadas.
- Mensajes autodescriptivos: cada mensaje devuelto al cliente contiene la información suficiente para describir cómo el cliente debe procesar la información.
- Hipermedios es el motor del estado de la aplicación: después de acceder a un recurso, el cliente REST debe ser capaz de descubrir mediante hipervínculos todas las otras acciones que están disponibles actualmente.
Estas limitaciones pueden parecer demasiadas, pero son mucho más simples que un protocolo indicado. Por esta razón, las API de RESTful son cada vez más frecuentes que SOAP.
SOA frente a la arquitectura de microservicios
Los dos enfoques de arquitectura que más usan API remotas son la arquitectura orientada al servicio (SOA) y la arquitectura de microservicios. SOA, el más antiguo de los dos enfoques, comenzó como una mejora de las aplicaciones monolíticas. En lugar de utilizar una única aplicación que haga todo, algunas funciones pueden ser proporcionadas por diferentes aplicaciones sin conexión directa a través de un patrón de integración, como un bus de servicios empresariales (ESB).
Si bien SOA, en muchos aspectos, es más simple que una arquitectura monolítica, conlleva un riesgo de cambios en cascada en todo el entorno si las interacciones de los componentes no se comprenden claramente. Esta complejidad adicional vuelve a presentar algunos de los problemas que SOA pretende solucionar.
Las arquitecturas de microservicios son similares a los patrones SOA en cuanto a que los servicios son especializados y no tienen conexión directa. Pero avanzan un poco más al derribar las arquitecturas tradicionales. Los servicios en la arquitectura de microservicios usan un marco de mensajería común, como las API de RESTful. Utilizan API de RESTful para comunicarse entre sí, sin transacciones de conversión de datos complejas ni capas de integración adicionales. Usar API de RESTful permite, e incluso alienta, una entrega más rápida de nuevas funciones y actualizaciones. Cada servicio es discreto. Un servicio se puede reemplazar, mejorar o abandonar, sin afectar los otros servicios de la arquitectura. Esta arquitectura liviana optimiza los recursos distribuidos o en la nube, y admite la escalabilidad dinámica de servicios individuales.