Publicado: el 9 de abril de 2024
Colaborador: Michael Goodwin
Una API, o interfaz de programación de aplicaciones, es un conjunto de reglas o protocolos que permiten que las aplicaciones de software se comuniquen entre sí para intercambiar datos, características y funcionalidades.
Las API simplifican y aceleran el desarrollo de software y aplicaciones permitiendo a los desarrolladores integrar datos, servicios y capacidades de otras aplicaciones, en lugar de desarrollarlas desde cero. Las API también ofrecen a los propietarios de aplicaciones una forma sencilla y segura de poner los datos y las funciones de sus aplicaciones a disposición de los departamentos de su organización. Los propietarios de aplicaciones también pueden compartir o comercializar datos y funciones con asociados de negocios o terceros.
Las API permiten compartir solo la información necesaria, manteniendo ocultos otros detalles internos del sistema, lo que ayuda a la seguridad del sistema. Los servidores o dispositivos no tienen que exponer completamente los datos: las API permiten compartir pequeños paquetes de datos, relevantes para la solicitud específica.
La documentación de la API es como un manual de instrucciones técnicas que proporciona detalles sobre una API e información para los desarrolladores sobre cómo trabajar con una API y sus servicios. Una documentación bien diseñada promueve una mejor experiencia de API para los usuarios y, en general, hace que las API sean más exitosas.
Descubra cómo la automatización inteligente puede hacer que sus operaciones comerciales sean una ventaja competitiva.
Regístrese para obtener la guía para poner en funcionamiento FinOps
Es útil pensar en la comunicación de la API en términos de una solicitud y respuesta entre un cliente y un servidor. La aplicación que envía la solicitud es el cliente y el servidor proporciona la respuesta. La API es el puente que establece la conexión entre ellos.
Una forma sencilla de entender cómo funcionan las API es examinar un ejemplo común: el procesamiento de pagos de terceros. Cuando un usuario compra un producto en un sitio de comercio electrónico, es posible que se le pida que "pague con PayPal" u otro tipo de sistema externo. Esta función depende de las API para realizar la conexión.
Cuando el comprador hace clic en el botón de pago, se envía una llamada a la API para recuperar la información. Esta es la solicitud. Esta solicitud se procesa desde una aplicación al servidor web a través del identificador uniforme de recursos (URI) de la API e incluye un verbo de solicitud, una cabecera y, a veces, un cuerpo de solicitud.
Tras recibir una solicitud válida desde la página web del producto, la API llama al programa externo o al servidor web, en este caso, al sistema de pago externo.
El servidor envía una respuesta a la API con la información solicitada.
La API transfiere los datos a la aplicación solicitante inicial, en este caso, el sitio web del producto.
Si bien la transferencia de datos difiere según el servicio web que se utilice, las solicitudes y respuestas se realizan a través de una API. No hay visibilidad en la interfaz de usuario, lo que significa que las API intercambian datos dentro de la computadora o la aplicación, y aparecen ante el usuario como una conexión sin fisuras.
Las API se pueden clasificar por casos de uso: API de datos, API de sistemas operativos, API remotas y API web.
Se utilizan para conectar aplicaciones y sistemas de gestión de bases de datos.
Se usan para definir cómo las aplicaciones usan los servicios y recursos del sistema operativo.
Se utilizan para definir cómo interactúan las aplicaciones en diferentes dispositivos.
Se utilizan para permitir la transferencia de datos y funcionalidades a través de Internet mediante el protocolo HTTP.
Hoy en día, la mayoría de las API son API web. Las API web son un tipo de API remota (es decir, que utiliza protocolos para manipular recursos externos) que expone los datos y funcionalidades de una aplicación a través de Internet.
Los cuatro tipos principales de API web son:
Las API abiertas son interfaces de programación de aplicaciones de código abierto que se puede acceder con el protocolo HTTP. También conocidas como API públicas, han definido endpoints de API y formatos de solicitud y respuesta.
Las API de socios conectan a asociados de negocios estratégicos. Normalmente, los desarrolladores acceden a estas API en modo de autoservicio a través de un portal de desarrolladores de API público. Aún así, deben completar un proceso de incorporación y obtener credenciales de inicio de sesión para acceder a las API de socios.
Las API internas o privadas permanecen ocultas para los usuarios externos. Estas API privadas no están disponibles para usuarios fuera de la empresa. En cambio, las organizaciones las utilizan para mejorar la productividad y la comunicación entre diferentes equipos de desarrollo internos.
Las API compuestas combinan múltiples API de datos o servicios. Permiten a los programadores acceder a varios endpoints en una sola llamada. Las API compuestas son útiles en la arquitectura de microservicios, donde la realización de una única tarea puede requerir información de varias fuentes.
Dado que las API permiten a las organizaciones abrir el acceso a sus recursos mientras mantienen la seguridad y el control, se han convertido en un aspecto valioso de las aplicaciones empresariales y personales modernas.
Estos son algunos ejemplos de API que los usuarios suelen encontrar:
Un ejemplo popular de API es la función que permite a las personas iniciar sesión en sitios web utilizando los datos de acceso de sus perfiles de Facebook, X o Google. Esta práctica característica permite a cualquier sitio web utilizar una API de uno de los servicios más populares para una autenticación rápida. Esta capacidad ayuda a los usuarios a ahorrarse el tiempo y la molestia de configurar un nuevo perfil para cada aplicación web o nueva membresía.
Estos “dispositivos inteligentes” ofrecen funciones adicionales, como pantallas táctiles habilitadas para Internet y recopilación de datos, a través de API. Por ejemplo, un refrigerador inteligente puede conectarse a aplicaciones de recetas o tomar y enviar notas a teléfonos móviles a través de mensajes de texto. Las cámaras internas se conectan a varias aplicaciones para que los usuarios puedan ver el contenido del refrigerador desde cualquier lugar.
Los sitios web de reservaciones de viajes reúnen miles de vuelos y muestran las opciones más económicas para cada fecha y destino. Las API habilitan este servicio al proporcionar a los usuarios de la aplicación acceso a la información más reciente sobre la disponibilidad de hoteles y aerolíneas.
Este acceso está disponible a través de un navegador web o de la propia aplicación de la empresa de reservaciones de viajes. Con un intercambio autónomo de datos y solicitudes, las API reducen drásticamente el tiempo y el esfuerzo que supone buscar vuelos o alojamientos disponibles.
Las aplicaciones de navegación utilizan API principales que muestran mapas estáticos o interactivos. Estas aplicaciones también utilizan otras API y funciones para proporcionar a los usuarios indicaciones, límites de velocidad, puntos de interés, advertencias de tráfico y más. Los usuarios se comunican con una API cuando trazan rutas de viaje o rastrean artículos en movimiento, como un vehículo de reparto.
Las empresas de redes sociales utilizan API para permitir que otras entidades compartan e incrusten contenido presentado en aplicaciones de redes sociales en sus propios sitios. Por ejemplo, la API de Instagram permite a las empresas insertar su cuadrícula de Instagram en su sitio web y que la cuadrícula se actualice automáticamente a medida que los usuarios agregan nuevas publicaciones.
Las API son una parte integral del crecimiento de los productos de software como servicio (SaaS). Las plataformas como las CRM (herramientas de gestión de relaciones con los clientes) suelen incluir una serie de API integradas que permiten a las empresas integrarse con aplicaciones que ya utilizan, como mensajería, redes sociales y aplicaciones de correo electrónico.
Esta integración reduce drásticamente el tiempo dedicado a cambiar entre aplicaciones para tareas de ventas y marketing. También ayuda a reducir o evitar los silos de datos que puedan existir entre departamentos que utilizan diferentes aplicaciones.
Tradicionalmente, API hacía referencia a una interfaz conectada a una aplicación creada con cualquiera de los lenguajes de programación de bajo nivel. Sin embargo, las API modernas varían en sus arquitecturas y en el uso de formatos de datos. Por lo general, están diseñadas para HTTP, lo que da como resultado interfaces amigables para los desarrolladores, a las que se puede acceder fácilmente y comprender ampliamente las aplicaciones escritas en Java, Ruby, Python y muchos otros lenguajes.
A medida que el uso de las API web ha aumentado, ha llevado al desarrollo y uso de ciertos protocolos, estilos, estándares y lenguajes. Estas estructuras proporcionan a los usuarios un conjunto de reglas definidas, o especificaciones de API, que crean tipos de datos, comandos y sintaxis aceptados. En efecto, estos protocolos de API facilitan el intercambio estandarizado de información.
SOAP es una especificación de protocolo de mensajería ligera basada en XML que permite a los endpoints enviar y recibir datos a través de una serie de protocolos de comunicación, entre ellos SMTP (protocolo simple de transferencia de correo) y HTTP (protocolo de transferencia de hipertexto). SOAP es independiente, lo que permite a las API de SOAP compartir información entre aplicaciones o componentes de software que se ejecutan en entornos distintos o están escritos en lenguajes diferentes.
La llamada a procedimiento remoto (RPC) es un protocolo que proporciona el paradigma de comunicaciones de alto nivel que se usa en el sistema operativo. RPC supone la existencia de un protocolo de transporte de bajo nivel, como el protocolo de control de transmisión/protocolo de Internet (TCP/IP) o el protocolo de datagramas de usuario (UDP), para transportar los datos del mensaje entre programas que se comunican.
RPC implementa un sistema lógico de comunicaciones de cliente a servidor diseñado específicamente para el soporte de aplicaciones de red. El protocolo RPC permite a los usuarios trabajar con procedimientos remotos como si los procedimientos fueran locales.1
El protocolo XML-RPC se basa en un formato XML específico para transferir datos. XML-RPC es más antiguo que SOAP, pero más simple y relativamente ligero, ya que utiliza un ancho de banda mínimo.
Al igual que XML-RPC, JSON-RPC es una llamada a procedimiento remoto que utiliza JSON (notación de objetos JavaScript) en lugar de XML. JSON es un formato ligero para el intercambio de datos que es fácil de analizar y utiliza pares de nombre/valor y listas ordenadas de valores. Debido a que JSON utiliza estructuras de datos universales, se puede utilizar con cualquier lenguaje de programación.
gRPC es un marco de trabajo de RPC de código abierto y alto rendimiento desarrollado inicialmente por Google. gRPC usa el formato de datos de protocolo de red HTTP/2 y búferes de protocolo y se usa normalmente para conectar servicios en una arquitectura de microservicios.
Las API de WebSocket permiten la comunicación bidireccional entre el cliente y el servidor. Este tipo de API no requiere que se establezca una nueva conexión para cada comunicación, una vez que se establece la conexión, permite un intercambio continuo. Esto hace que las API de Web Socket sean ideales para la comunicación en tiempo real.
REST es un conjunto de principios de arquitectura de API web. Las API de REST, también conocidas como API RESTful, son API que cumplen con ciertas restricciones de la arquitectura de REST. Las API de REST utilizan solicitudes HTTP como GET, PUT, HEAD y DELETE para interactuar con los recursos. REST hace que los datos estén disponibles como recursos, y cada recurso está representado por un URI único. Los clientes solicitan un recurso proporcionando su URI.
Las API de REST no tienen estado, es decir, no guardan los datos del cliente entre solicitudes. Es posible crear API de RESTful con protocolos SOAP, pero los profesionales suelen considerar ambas normas como especificaciones contrapuestas.
GraphQL es un lenguaje de consulta de código abierto y un tiempo de ejecución del lado del servidor que especifica cómo los clientes deben interactuar con las API.2 GraphQL permite a los usuarios realizar solicitudes de API con solo unas pocas líneas, en lugar de tener que acceder a endpoints complejos con muchos parámetros. Esta capacidad puede facilitar la generación y respuesta a las consultas de API, en particular las solicitudes más complejas o específicas que se dirigen a varios recursos.
SOAP y REST representan diferentes enfoques para el diseño de API, describiendo reglas y estándares sobre cómo una API debe interactuar con otras aplicaciones. SOAP es un protocolo, mientras que REST es un conjunto de restricciones que constituyen un estilo arquitectónico. Ambos utilizan HTTP para intercambiar información.
REST se considera a menudo una alternativa más sencilla que SOAP porque es ligero, flexible, transparente y relativamente fácil de usar; SOAP requiere que los usuarios escriban más código para completar cada tarea que REST.
SOAP es más determinista y robusto (debido a la verificación de tipos), y sus defensores argumentan que es más fácil de usar debido a la compatibilidad con SOAP integrada en muchas herramientas de desarrollo.3 SOAP cuenta con un cumplimiento integrado y los desarrolladores suelen considerarlo un protocolo más seguro, más adecuado para situaciones con requisitos estrictos de integridad de datos.
Los sistemas RESTful, que admiten mensajería en diferentes formatos, como texto sin formato, HTML, YAML, XML y JSON, mientras que SOAP solo permite XML. Cada uno tiene sus puntos fuertes y la “elección correcta” puede depender del caso de uso. Sin embargo, la capacidad de admitir múltiples formatos para almacenar e intercambiar datos es una de las razones por las que REST es una opción predominante para crear API públicas.
GraphQL es un lenguaje de consulta y tiempo de ejecución de API que Facebook desarrolló internamente en 2012 antes de que se convirtiera en código abierto en 2015. GraphQL y REST no tienen estado y utilizan un modelo cliente/servidor y HTTP. GraphQL resuelve algunas limitaciones de REST, por ejemplo, proporcionando la capacidad de orientar con mayor precisión los recursos deseados con una sola solicitud.
Las API REST siguen una estructura fija y siempre devuelven un conjunto de datos completo para un objeto específico. Si la solicitud es más compleja y abarca varios recursos, por ejemplo, el cliente debe enviar solicitudes separadas para cada recurso. Estas limitaciones pueden provocar problemas de recuperación insuficiente o excesiva.
Leer más sobre GraphQL frente a REST aquí
Ni las API de REST ni las de GraphQL son inherentemente superiores. Son herramientas diferentes que se adaptan a diferentes tareas.
Por lo general, REST es más fácil de implementar y puede ser una buena opción cuando se prefiere un protocolo de comunicación sencillo y almacenable en caché con controles de acceso estrictos (para sitios de comercio electrónico públicos como Shopify y GitHub, por ejemplo).
Las API GraphQL permiten una obtención de datos más flexible y eficiente, lo que puede mejorar el rendimiento del sistema y la facilidad de uso para los desarrolladores. Estas características hacen que GraphQL sea especialmente útil para crear API en entornos complejos con requisitos frontales que cambian rápidamente.4
Un servicio web es un componente de software de Internet que facilita las transferencias de datos a través de una red. Dado que un servicio web expone los datos y la funcionalidad de una aplicación a otras aplicaciones, en efecto, cada servicio web es una API. Sin embargo, no todas las API son un servicio web.
Las API son cualquier componente de software que sirve como intermediario entre dos aplicaciones desconectadas. Si bien los servicios web también conectan aplicaciones, requieren una red para hacerlo. Los servicios web suelen ser privados y solo los usuarios aprobados pueden acceder a ellos.
Microservicios es un estilo arquitectónico que divide una aplicación en componentes independientes más pequeños, a menudo conectados mediante API de REST. La creación de una aplicación como una colección de servicios independientes permite a los desarrolladores trabajar en un componente de la aplicación independientemente de los demás, y hace que las aplicaciones sean más fáciles de probar, mantener y escalar.
La arquitectura de microservicios se ha generalizado con el auge de la computación en la nube y, junto con los contenedores y Kubernetes, es fundamental para el desarrollo de aplicaciones nativas de la nube.
Las API simplifican el diseño y el desarrollo de nuevas aplicaciones y servicios, así como la integración y la gestión de las existentes. También ofrecen beneficios significativos a los desarrolladores y a las organizaciones en general.
La empresa media utiliza casi 1,200 aplicaciones en la nube (enlace externo a ibm.com), muchas de las cuales están desconectadas. Las API permiten la integración para que estas plataformas y aplicaciones puedan comunicarse entre sí sin problemas. Gracias a esta integración, las empresas pueden automatizar los flujos de trabajo y mejorar la colaboración en el lugar de trabajo. Sin las API, muchas empresas carecerían de conectividad, lo que provocaría silos de información que comprometerían la productividad y el rendimiento.
Las API ofrecen flexibilidad, lo que permite a las empresas establecer conexiones con nuevos asociados de negocios y ofrecer nuevos servicios a su mercado existente. Esta flexibilidad también permite a las empresas acceder a nuevos mercados que pueden aumentar los rendimientos e impulsar la transformación digital.
Por ejemplo, la empresa Stripe comenzó como una API con solo siete líneas de código. Desde entonces, la compañía ha trabajado con muchas de las empresas más grandes del mundo. Stripe se ha diversificado para ofrecer préstamos y tarjetas corporativas, y ha recibido una valuación reciente de 65,000 millones de dólares (enlace externo a ibm.com).
Muchas empresas optan por ofrecer API gratuitas, al menos al principio, para poder crear una audiencia de desarrolladores en torno a su marca y forjar relaciones con posibles socios. Si la API otorga acceso a activos digitales valiosos, la empresa la monetiza vendiendo ese acceso. Esta práctica se conoce como economía de API.
Cuando AccuWeather (enlace externo a ibm.com) inició su portal de desarrollador de autoservicio para vender una amplia gama de paquetes de API, solo tardó 10 meses en atraer a 24,000 desarrolladores y vendió 11,000 claves API. Este movimiento ayudó a construir una comunidad próspera en el proceso.
Las API separan la aplicación solicitante de la infraestructura del servicio que responde y ofrecen capas de seguridad entre las dos a medida que se comunican. Por ejemplo, las llamadas a la API suelen requerir credenciales de autenticación. Los encabezados HTTP, cookies o cadenas de consulta pueden proporcionar seguridad adicional durante el intercambio de datos. Una puerta de enlace de API puede controlar el acceso para minimizar aún más las amenazas a la seguridad.
Las API brindan protección adicional dentro de una red. También pueden proporcionar otra capa de protección para los usuarios personales. Cuando un sitio web solicita la ubicación de un usuario (una API de ubicación proporciona esta información), el usuario puede decidir si permite o rechaza esta solicitud.
Muchos navegadores web y sistemas operativos móviles y de escritorio tienen estructuras de permisos integradas. Cuando una aplicación debe acceder a los archivos a través de una API, los sistemas operativos como iOS, macOS, Windows y Linux utilizan permisos para ese acceso.
Gestione el ciclo de vida de su API en varias nubes, impulse la socialización y optimice los esfuerzos de monetización en todo su ecosistema empresarial.
Conecte, automatice y desbloquee el potencial de negocio con soluciones de integración.
Conecte aplicaciones, datos, procesos de negocio y servicios, ya sea alojados on premises, en una nube privada o dentro de un entorno de nube pública.
Notas de pie de página
1“Remote Procedure Call”, ibm.com, 3 de noviembre de 2023
2“What is GraphQL”, Chrystal R. China, ibm.com, 8 de diciembre de 2023
3“Comparing REST and SOAP”, ibm.com, 5 de marzo de 2021
4“GraphQL vs API REST: ¿Cuál es la diferencia?”, Chrystal R. China, ibm.com, 29 de marzo de 2014