El término "API" significa interfaz de programación de aplicaciones.

Las API
actúan como puentes entre aplicaciones, lo que les permite comunicarse y
compartir datos. Por ejemplo, un panel de control que un equipo de marketing
utiliza para gestionar varias cuentas de redes sociales depende de las API, que
conectan las plataformas sociales de la empresa a la pantalla del panel de
control y extraen datos relevantes.
Un usuario típico de Internet se beneficia constantemente de las API, a menudo
sin darse cuenta. Las API conectan las fuentes públicas de datos, como los
sitios de previsión meteorológica, con aplicaciones comerciales para
advertirnos sobre las próximas tormentas. Los desarrolladores acceden
regularmente a la API de Google Maps para integrar mapas y servicios de
ubicación en sus sitios web. Los minoristas utilizan gateways de pago basados
en API, como PayPal y Stripe, para gestionar de forma segura las transacciones
financieras con los clientes.
¿Qué es una API?
Una API, o interfaz de programación de aplicaciones, es un conjunto de reglas y
protocolos que permite a las aplicaciones intercambiar datos, realizar acciones
e interactuar de una manera bien documentada. Cuando se realiza una
solicitud (por ejemplo, para una actualización meteorológica), la API procesa la
solicitud, ejecuta las acciones necesarias y devuelve una respuesta,
normalmente en un formato estándar, como los definidos por JSON o XML.
Conclusiones clave
 Una API es un intermediario que permite a dos programas de software
comunicarse entre sí y define cómo solicitan y reciben datos o
funcionalidades.
 Las API son esenciales para crear aplicaciones de software modernas
que conectan y comparten información.
 Las API desempeñan un papel crucial a la hora de permitir el uso de
servicios en la nube al permitirles integrar y compartir datos con
software on-premises.
API explicadas
Con las API, los desarrolladores pueden acceder a plataformas y servicios de
software de forma nativa desde las aplicaciones que están creando. Sin las API,
los datos tendrían que exportarse manualmente desde una aplicación,
prepararse y transformarse, y luego importarse manualmente a otra aplicación
cada vez que un usuario quisiera comprobar el clima o responder a un
comentario en un sitio de redes sociales.
En términos simples, hay tres partes involucradas en el proceso de
intercambio, de la siguiente manera:
 Cliente: la parte que realiza la solicitud
  Servidor: la parte que cumple la solicitud
 API: el intermediario que conecta a los dos de una manera bien
documentada y predecible
Piensa en un restaurante. Si todos los clientes entraran a la cocina para pedir
sus platos favoritos, se produciría un caos. En este escenario, la API
proporciona un menú (documentación) que enumera todos los servicios
(platos) que la cocina (aplicación de servidor) puede ofrecer. Explica qué
información debe proporcionar como cliente y en qué formato debe
presentarse su pedido.
La API actúa como camarero o intermedio, asegurándose de que los pedidos se
realicen y entreguen de una manera estandarizada.
Cómo funcionan las API
Las API funcionan especificando cómo deben interactuar los componentes de
software, lo que permite a los desarrolladores integrar diferentes sistemas y
compartir datos y funcionalidades sin necesidad de crear todo desde cero,
ahorrando tiempo y recursos. Las API suelen definir los métodos y protocolos
que se deben utilizar para la comunicación, así como los formatos de datos que
se pueden intercambiar.
Una API define cómo interactúan las aplicaciones proporcionando detalles que
incluyen:
 Puntos finales. URL específicas que definen dónde enviar datos y
solicitudes.
 Métodos. Instrucciones como GET para recuperar datos, POST para
enviar datos, PUT para actualizar datos y DELETE para eliminar datos.
 Parámetros. Detalles específicos necesarios para la solicitud, como la
ubicación de los datos meteorológicos o las credenciales de inicio de
sesión para las redes sociales.
 Respuestas. Formato de los datos devueltos por la aplicación, como
JSON o XML.
El desarrollador de la aplicación cliente que solicita datos escribe código para
realizar una llamada de API. Este código especifica:
 URL de punto final de API
 El método HTTP
 Cualquier parámetro necesario
La aplicación envía solicitudes al gateway de API de la aplicación del servidor,
que gestiona las solicitudes entrantes. El gateway de API direcciona la solicitud
al servicio adecuado dentro de la aplicación de destino. El servicio procesa la
solicitud y recupera los datos o realiza otra acción deseada.
A continuación, el servicio de destino prepara los datos de respuesta según la
definición de API y los envía de vuelta a través del gateway de API a la
aplicación solicitante, que recibe y analiza los datos y entrega el resultado
esperado al usuario final.
¿Por qué son importantes las API?
Debido a que proporcionan una forma estandarizada para que los
desarrolladores accedan a los datos y la funcionalidad de otras aplicaciones y
servicios, las API permiten a las empresas evitar volver a crear la rueda
proverbial. Esto ahorra tiempo y dinero. La estandarización también fomenta la
innovación y la escalabilidad al permitir la adición modular de nuevas
características y servicios sin interrumpir el funcionamiento de los sistemas
existentes.
A nivel empresarial, las API son fundamentales porque permiten a las empresas
automatizar tareas y procesos repetitivos al permitir que el software interactúe
directamente con otro software. Dado que la mayoría de las empresas están
trabajando para agregar automatización para liberar a los empleados para
tareas de nivel superior, la capacidad de las API para reducir las cargas de
trabajo manuales y aumentar la eficiencia operativa es una ventaja clave. Las
organizaciones que buscan aumentar el uso de los servicios en la nube
también dependen en gran medida de las API.
Componentes de API
Los componentes de API funcionan conjuntamente para permitir que diferentes
sistemas de software comuniquen e intercambien datos y funcionalidades.
Comprender estos componentes es esencial para integrar correctamente las
API en el software. Los componentes de API incluyen lo siguiente:
 Una especificación de API proporciona una descripción estructurada
de lo que hará la API y exactamente cómo interactuar con ella.
 El diseñador de API es una utilidad que ayuda a los desarrolladores a
crear API. Un diseñador de API puede ser tan simple como un plugin para
un entorno de desarrollo o una herramienta altamente especializada. El
objetivo es tener reglas incorporadas para validar y formatear la API, a
fin de ahorrar tiempo y agravación.
 Los portales de API son donde los desarrolladores encuentran y
comparten las API publicadas y revisan las especificaciones para saber si
una API puede ayudarles y cómo se puede utilizar. Los portales para las
API públicas a menudo están integrados en un sitio web de material de
apoyo, como términos y condiciones legales.
 El backend de API es el software que traduce una llamada de API en
acción para el cliente.
 Los gateways de API proporcionan la URL de una API, aplican reglas
que rigen el uso de esa API y dirigen la llamada de API al backend
 relevante. Normalmente, un gateway sabrá tanto la especificación de la
API como los detalles de las reglas que debe aplicar. Las reglas pueden
abordar la autenticación y la autorización, la gestión de certificados, la
limitación y limitación de frecuencia, la inspección y validación de la
carga útil, el enrutamiento inteligente basado en el contenido de la
cabecera o la carga útil, etc.
Las API también pueden incluir limitación de frecuencia, manejo de errores y
documentación para desarrolladores. Escribir una API sólida implica una serie
de decisiones, desde el estilo arquitectónico hasta las herramientas de diseño,
y es una habilidad invaluable para las organizaciones que buscan un futuro
nativo en la nube.
Ventajas de las API
Mediante el uso de API, los desarrolladores pueden conectar aplicaciones
distribuidas, por ejemplo, una aplicación para teléfonos inteligentes a un sitio
web de redes sociales o un sistema de nómina a una cuenta bancaria
empresarial. Debido a que las API permiten la creación de aplicaciones
prácticas a partir de servicios pequeños, individuales y conectados, pagan
beneficios en robustez y escalabilidad.
Si un servicio se rompe, la mayoría de la aplicación puede continuar. Los
beneficios adicionales incluyen:
 Agilidad. Las API permiten a los desarrolladores seleccionar la mejor
tecnología para cada problema que se debe resolver.
 Más rapidez en el desarrollo. Las API permiten a los desarrolladores
conectar la funcionalidad existente en lugar de crearlo todo desde cero.
 Innovación. Las API fomentan la colaboración y la experimentación al
permitir a los desarrolladores descubrir nuevos servicios y probarlos sin
una gran cantidad de inversión.
 Más control. Las API se pueden equipar con estrictos controles de
autorización para limitar granularmente a qué datos o acciones puede
acceder una aplicación.
 Escalabilidad. Las API permiten a las aplicaciones manejar una mayor
demanda mediante la subcontratación de tareas a otros servicios. Por
ejemplo, en lugar de mantener su propio sistema de procesamiento de
pagos, un pequeño minorista puede optar por una API de pago como
Stripe o PayPal. Esto descarga una tarea compleja. Ahora el vendedor
puede centrarse en hacer crecer su negocio principal mientras deja el
procesamiento de pagos a los expertos y aumenta la confianza del
cliente.
Desafíos de las API
Para todos los inconvenientes de las API, hay desafíos en torno a la
complejidad, el costo y la seguridad a considerar al diseñar aplicaciones que
hacen uso de llamadas de API y al crear sus propias API. El software que
depende de varias API puede volverse difícil de gestionar y mantener,
especialmente si el proveedor de API realiza actualizaciones o cambios
frecuentes.
Entre los retos específicos a los que se debe hacer frente figuran los siguientes:
 Selección de API. Con la gran cantidad de API disponibles, elegir el
mejor ajuste puede ser una tarea desalentadora. De hecho, es posible
que no haya una única API perfecta; es posible que deba combinar datos
y funcionalidades de múltiples fuentes.
 Costo. Si bien muchas API son gratuitas de usar, tenga en cuenta los
límites de llamadas y funciones. En función de la aplicación y el público,
puede que necesites suscripciones de pago para determinadas funciones
o capacidades. ¿Pagarás una tarifa plana o basada en el uso? El costo
continuo de mantener sus conexiones de API también debe tenerse en
cuenta en las decisiones de arquitectura.

Si utiliza un número significativo de API o tiene un volumen importante

en algunas, busque un plan de uso de API para mantener los costos bajo
control.
 Complejidad de integración. Incluso después de encontrar una API
adecuada, integrarla con tu aplicación puede ser un trabajo complejo.
Las API de diferentes proveedores pueden tener diferentes protocolos,
formatos de datos y mecanismos de autenticación. Reducir las brechas
puede requerir un esfuerzo significativo de desarrollo.
 Rendimiento. El rendimiento, o no, de una API puede frustrar a las
personas que utilizan tu aplicación. Las API pueden introducir latencia
que provoca tiempos de respuesta lentos y un procesamiento de datos
estancado. Recuerde, el empleado o el cliente no culparán al proveedor
de API. Es el nombre de la compañía en la aplicación.
 Seguridad. Hacer que las API sean más fáciles de detectar aumenta el
riesgo de uso indebido, por lo que las empresas deben tener en cuenta
la seguridad. Afortunadamente, con las herramientas adecuadas, crear
API seguras es razonablemente sencillo. Los mecanismos de
autenticación, como claves de API, tokens u otras credenciales, pueden
garantizar que solo las aplicaciones autorizadas accedan a los sistemas.
Asegúrese de revisar los estándares de cifrado de datos de la API.
Además, una API bien diseñada ocultará cómo se implementa su
backend, lo que permitirá a los equipos realizar cambios sin afectar
negativamente al cliente.
 Dependencia de proveedor. Confiar en un proveedor de API específico
para una funcionalidad importante para tu aplicación puede bloquearte
 en ese ecosistema. Si desea cambiar de proveedor de API en el futuro,
puede ser una operación costosa y disruptiva.
 Problemas de control de versiones. Como la mayoría del software,
las API no son estáticas. Evolucionan para agregar nuevas
funcionalidades y abordar los cambios técnicos y de seguridad. Las
nuevas versiones pueden introducir cambios de código que interrumpan
la aplicación. E incluso si no hay fallos, mantener un registro de las
diferentes versiones e integraciones de API en uso puede ser una carga
importante.
Relacionado, no todos los desarrolladores de API emiten la documentación clara
y completa que es esencial para que sus desarrolladores utilicen e integren una
API, así que elija cuidadosamente a los socios proveedores.
Errores comunes de API
Para aquellos que buscan desarrollar API, hay algunos obstáculos,
particularmente en torno a la elección de especificaciones y la subestimación
de la demanda. Un principio de buen diseño de API es abstraer y proteger al
consumidor de los cambios en la forma de implantar el backend. Su diseño de
API refleja directamente el almacenamiento de datos subyacente, por ejemplo,
para que si cambian las estructuras de datos internas, la API se vea afectada,
lo que podría afectar al cliente de API.
Otros errores que se deben evitar incluyen:
Mala documentación. Una documentación clara y detallada es esencial para
el éxito de su API. Por ejemplo, cuando describe una fecha, debe tener un
formato claro. En Europa, una fecha suele representarse como día, mes y año,
mientras que en América del Norte, el pedido es mes, día y año. No ser
explícito en estos detalles puede dar lugar a problemas de calidad de datos y,
en el peor de los casos, su API rompe una aplicación.
Sin considerar los volúmenes de datos de producción. Durante el
desarrollo de API, las pruebas utilizan conjuntos de datos relativamente
pequeños. En producción, los volúmenes de datos suelen ser mucho mayores,
lo que hace que las llamadas de API intenten comunicar grandes cantidades de
datos en una sola solicitud. Esto puede dar lugar a una serie de problemas, en
función de la red entre el cliente y el backend. En el peor de los casos, la
solicitud puede generar un exceso de demanda en el backend de API, lo que
puede provocar un fallo en la llamada de API.
También se pueden cometer errores al definir políticas para el gateway de API.
Estos errores suelen implicar no proporcionar suficiente seguridad, lo que
puede permitir a los actores maliciosos cambiar o acceder incorrectamente a
los datos o incluso utilizar la API como una forma de atacar la red. OWASP
Foundation analiza y recopila este tipo de problemas, y los errores más
comunes se informan en su conocida lista de los 10 principales riesgos de
seguridad de API.
La confusión de los roles de un gateway de API y el backend de API es otro
error común. Ambas capacidades necesitan procesar las API a medida que se
reciben, y es fácil combinar los dos elementos. Sin embargo, el trabajo del
gateway consiste en filtrar y enrutar las solicitudes al lugar correcto muy
rápidamente. El backend de API necesitará más tiempo para procesar cada
solicitud, ya que ofrece lógica de negocio.
Recuerda que la relación entre las llamadas de API y el backend de API no es de
uno a uno.
Tipos de API
Existen cuatro tipos principales de API. Lo que elijas dependerá de tu caso de
uso. Considera planes a corto y largo plazo para la aplicación antes de
establecerse en un modelo: el intercambio en una API diferente es factible,
pero aumenta los costos y la complejidad.
 Cualquier usuario puede utilizar API públicas para acceder a los datos
de un servidor u otros servicios desde una aplicación cliente. Los usos
comunes de las API públicas incluyen la recuperación de datos de tráfico
y meteorológicos y la gestión de procesos de inicio de sesión de
terceros. Las API públicas suelen permitir que cualquier aplicación utilice
un servicio. Este acceso podría ser una acción simple, como recuperar la
hora actual, o algo más complejo, como recuperar una imagen de radar
meteorológico o una lista detallada de direcciones desde el punto A
hasta el punto B. Debido a que las API públicas tienden a ser
ampliamente utilizadas, se tiene mucho cuidado de no cambiarlas a
menos que sea absolutamente necesario para no romper la
funcionalidad de las aplicaciones.
 Las API privadas se desarrollan solo para uso interno y no se publican
ampliamente. Normalmente, las API privadas permiten que las
aplicaciones de un proveedor se comuniquen con los servidores de ese
proveedor. Por ejemplo, la aplicación bancaria de su teléfono utiliza API
privadas para acceder a los servicios únicos de su banco específico.
 Las API de partners se desarrollan para su uso entre organizaciones
específicas. Los detalles de la API se revelan a un conjunto limitado de
socios. Por ejemplo, una plataforma de base de datos en la nube puede
aceptar asociarse con un número determinado de proveedores de
análisis. Esto conducirá a API de socios que conecten la base de datos
con las plataformas de análisis de manera eficiente.
 Las API compuestas se encadenan para una función concreta y pueden
ser una combinación de API públicas, privadas y de socios. Un ejemplo
de una API encadenada que utiliza API públicas y privadas es la
integración entre una aplicación meteorológica y una aplicación de
seguimiento de estado físico. La API pública de la aplicación
meteorológica proporciona datos como la temperatura y la humedad a la
aplicación de seguimiento de estado físico. Su API privada aporta datos
 sobre el ritmo y la distancia del propietario y los combina con factores
ambientales para calcular las calorías quemadas.
Ejemplos de API
La mayoría de las personas están familiarizadas con las API de los
consumidores, como el clima o la ubicación. Sin embargo, hay un universo de
API sofisticadas que permiten a las empresas aprovechar la funcionalidad,
desde los servicios en la nube hasta las bases de datos y las aplicaciones
empresariales sólidas.
Por ejemplo, Oracle ofrece una amplia gama de API en todos sus servicios. Las
empresas que utilizan Oracle Cloud Infrastructure (OCI) pueden aprovechar las
API para la gestión programática de redes virtuales, incluida la creación, la
configuración y la gestión de subredes, listas de seguridad y tablas de rutas.
Una API de Compute permite a los administradores iniciar, parar, reiniciar y
configurar instancias informáticas en OCI. Otras API conectan a los equipos de
TI con el almacenamiento de objetos y las funciones de gestión de identidad y
acceso.
Las startups innovadoras también utilizan API. Por ejemplo, Inworld.ai ofrece
personajes virtuales basados en IA para juegos de rol en línea. Mediante el uso
de API, los desarrolladores pueden crear personajes no jugables (NPC) que
interactúan con los jugadores de una manera realista y atractiva. Las API
permiten a los diseñadores de juegos especificar los atributos, la personalidad
y los comportamientos de un personaje, lo que les permite personalizar los NPC
para agregar profundidad y variedad a sus juegos. Los caracteres virtuales
pueden comprender y responder a entradas de texto o voz, todo a través de
API.
Desde el uso de las API por parte de Dominoes para integrarse con asistentes
de voz para que los clientes puedan pedir pizza sin tocar un dispositivo a Uber
utilizando API para enlazar a datos en tiempo real y ajustar dinámicamente los
precios de los viajes en función de la demanda y las condiciones de tráfico,
esta tecnología está impulsando la innovación real ahora.
Casos de uso de API
Para la persona promedio, las API que permiten la integración de redes sociales
y el procesamiento de pagos serán familiares. Muchos sitios web y aplicaciones
utilizan API para permitir funciones de redes sociales populares, como
compartir contenido, mientras que las plataformas de comercio electrónico
utilizan API para conectarse con pasarelas de pago como Stripe o PayPal.
Pero esa no es la única forma en que las API facilitan nuestra vida cotidiana.
Permiten los servicios de geolocalización utilizados por las aplicaciones que
proporcionan servicios de viaje compartido o entrega de alimentos que
dependen de API de asignación para encontrar la ubicación del hogar o destino
de un cliente.
En el ámbito empresarial, los casos de uso de API incluyen permitir a los
equipos interactuar con los recursos en la nube, como las aplicaciones que
utilizan para las funciones financieras o de servicio al cliente. Las API también
son lo que impulsa la comunicación y el intercambio de datos entre los
dispositivos IoT y sus sistemas de control.
Si trabajas en una oficina inteligente donde las luces y la temperatura se
ajustan automáticamente, ese es un caso de uso de API.
Protocolos de API
Existen varios protocolos, o estilos arquitectónicos, para exponer las API a los
desarrolladores. Estos enfoques permiten al desarrollador saber cómo debe
esperar que funcione un conjunto de API y, en general, qué mecanismo
utilizará para acceder a la API desde sus propios programas.
Los estilos arquitectónicos comunes incluyen los siguientes:
 Transferencia de estado representativa (REST)
Esta es quizás la arquitectura más popular para acceder a recursos y
servicios en la web. En muchos entornos, un cliente pasa por procesos
que cambian su estado con respecto al servidor. Por ejemplo, si quieres
conocer tu saldo bancario, tendrás que pasar de un estado no
autenticado a uno autenticado. El servidor y el cliente mantienen ese
estado autenticado una vez que se ha establecido. Por el contrario, las
API de REST no tienen estado. Si un desarrollador desea usar una API de
REST para comprobar un saldo bancario, la solicitud deberá incluir
suficiente información para autenticar al usuario que realiza la solicitud.
Una vez procesada la solicitud, no se conserva ninguna información de
estado. Si el usuario desea realizar otra solicitud similar, debe volver a
proporcionar la información de autenticación con la solicitud. Una
ventaja de las API de REST es que los servidores no necesitan realizar un
seguimiento del estado de los clientes, lo que puede simplificar en gran
medida la arquitectura del servidor.
 Llamadas a procedimientos remotos (RPC)
En las aplicaciones tradicionales, las llamadas a procedimientos, a veces
llamadas a funciones, se utilizan para acceder a los dispositivos y
servicios del equipo en el que se ejecuta la aplicación. Abrir y leer
archivos o escribir en la pantalla de la computadora u otros dispositivos
son funciones manejadas a través de llamadas de procedimiento. De
esta manera, el sistema operativo proporciona una capa de abstracción
entre la aplicación y el hardware real de la computadora. Los
programadores de aplicaciones no necesitan saber nada sobre la
pantalla de la computadora; solo usan una llamada de procedimiento.
Del mismo modo, las llamadas de procedimiento pueden permitir que
una aplicación utilice un recurso en una red. Puede que los archivos del
usuario no estén en el equipo local, sino en un servidor de red. Una
llamada a procedimiento remoto realiza el trabajo. Muchas veces, la
 aplicación no sabrá si el recurso que desea utilizar es local o remoto. El
sistema operativo lo calcula y toma las medidas adecuadas para cumplir
con la solicitud. Por lo general, los RPC pueden utilizar cualquier formato
para acceder a una función; las conversaciones sobre cómo funcionan
las llamadas suelen ser el dominio del sistema operativo.

Las llamadas al sistema operativo son solo un tipo de RPC. Otros tipos se
pueden desarrollar para hacer casi cualquier cosa. Por ejemplo, una
compañía puede optar por crear su propia aplicación para realizar un
seguimiento de las horas de trabajo. Los desarrolladores podrían utilizar
las funciones básicas de red para crear procedimientos que permitan a
las aplicaciones móviles informar de los registros de entrada o salida a
los servidores centrales. Varias bibliotecas facilitan este desarrollo,
mientras que el uso de una arquitectura estándar como REST puede ser
útil, ya que otros desarrolladores tendrán más probabilidades de
comprender cómo funciona la RPC.
 Protocolo simple de acceso a objetos (SOAP)
Al igual que REST, SOAP proporciona una forma de acceder a los
servicios en Internet. Utiliza XML para definir el formato de las
solicitudes y puede ejecutarse en una amplia variedad de protocolos de
transporte, lo que significa que puede ser independiente del proveedor.
SOAP se utiliza con mayor frecuencia para acceder a servicios web, con
HTTP que actúa como capa de transporte. Si una aplicación desea
recuperar una descripción del producto, creará el documento XML
adecuado y lo enviará a un servidor web que conozca el producto. El
servidor web devolvería su propio documento XML, incluida la
información del producto solicitada. Dado que SOAP está destinado a
recuperar objetos, las acciones se limitan a GET, POST, PUT y DELETE, lo
que hace que la estructura del verbo del protocolo sea extremadamente
simple.
Integraciones de API
Las integraciones de API conectan aplicaciones y les permiten intercambiar
datos y funcionalidades. Imagina integraciones como líneas telefónicas que
permiten comunicaciones abiertas de ida y vuelta.
Hay tres componentes involucrados.
Las API mismas proporcionan las reglas y especificaciones que determinan
cómo se pueden comunicar las aplicaciones. Las API definen qué datos se
pueden intercambiar, cómo formatearlos y qué acciones se pueden disparar.
La aplicación de servidor expone sus funcionalidades o datos a través de
una API. Por ejemplo, un servicio en la nube podría ofrecer una API que ayude a
los equipos de TI a poner en marcha rápidamente nuevas instancias o agregar
asientos.
La aplicación cliente utiliza API para solicitar datos o funcionalidad de la
aplicación del servidor. Una aplicación de viaje compartido, por ejemplo, utiliza
la API de un servicio meteorológico para ajustar los precios cuando llueve o por
encima o por debajo de ciertos umbrales de temperatura.
El proceso real implica unos pocos pasos, comenzando con el desarrollador de
la aplicación cliente seleccionando una API adecuada. El cliente utiliza claves
de API, tokens u otras credenciales para autenticarse con la API deseada y
obtener autorización para acceder a datos o acciones específicos. A
continuación, realiza solicitudes o llamadas a la API del servidor que solicitan
los datos o la acción exactos deseados.
La aplicación servidora procesa la solicitud y, si está autorizada, realiza la
acción o recupera los datos y los envía al cliente, a través de la API, en un
formato estructurado, como JSON o XML.
API y transformación digital
La transformación digital se trata de la nube, y las API son la piedra angular de
las arquitecturas nativas de la nube. Las API permiten la integración de
servicios y sistemas en la nube, y permiten a las empresas conectar
aplicaciones heredadas con sus nuevos servicios en la nube, lo que permite
una transición gradual hacia un futuro digital sin interrumpir las operaciones. Y
con las API, las empresas pueden responder rápidamente a los cambios y
oportunidades del mercado. Piensa en crear servicios modernos, como
pasarelas de pago, plataformas de redes sociales y herramientas de análisis,
directamente en tus aplicaciones.
Otra tecnología transformadora y basada en API son los microservicios, un
enfoque arquitectónico para el desarrollo moderno de aplicaciones que
favorece servicios y funciones independientes. En una arquitectura de
microservicios, una aplicación se divide en bloques de creación contenidos que
realizan de manera eficiente una sola tarea. Los microservicios se comunican
con otras aplicaciones o servicios mediante API. Una aplicación podría tener
solo unos pocos microservicios, o podría estar formada por cientos o incluso
miles de partes móviles. Las aplicaciones basadas en microservicios se amplían
más rápido al mantener los elementos individuales independientes. Esto
proporciona la agilidad y flexibilidad necesarias para las iniciativas de
transformación digital que pueden verse obstaculizadas por las arquitecturas
monolíticas utilizadas en el desarrollo de software heredado.
Las empresas nativas de la nube que abrazan los microservicios pueden
moverse rápidamente para aprovechar nuevas oportunidades y adoptar la
automatización. Las API sustentan esa estrategia.
Tendencias de API
Las empresas están desarrollando API para impulsar el crecimiento continuo de
la nube, la inteligencia artificial (IA) y el aprendizaje automático (ML), con
solicitudes y resultados que se comunican a través de API. Pero las API en sí
también están viendo avances.
Un ejemplo son las puertas de enlace inversas (de salida). Normalmente, el
trabajo de un gateway de API es el de campo de las solicitudes entrantes. Sin
embargo, hay situaciones en las que un gateway de API funciona como un
proxy de Internet especializado, proporcionando infraestructura para dirigir el
tráfico de la red de aplicaciones al tiempo que permite a los equipos de TI
supervisar lo que está sucediendo. Cuando la única forma de que el tráfico
salga de una red es a través del gateway de API, utilizando API externas
aprobadas, el departamento de TI puede auditar paquetes que salen de la red
y comprender mejor lo que está sucediendo con sus datos.
Los gateways de API también pueden realizar un seguimiento del uso de
servicios imputables, lo que garantiza que el servicio se esté utilizando
correctamente y que los ingresos lleguen según lo esperado. Además, los
gateways pueden ayudar a probar nuevas versiones de aplicaciones antes del
despliegue. Durante la prueba, puede que sea necesario dirigir las llamadas en
función de si la solicitud se originó en el sistema de producción o en el que se
está probando. La puerta de enlace puede derivar la información necesaria y
realizar la redirección.
Las nuevas técnicas de limitación y limitación de frecuencia de API ayudan a
los equipos de TI a gestionar el acceso a las API y evitar ataques. La limitación
de frecuencia restringe el número de llamadas de API que puede realizar una
aplicación en un marco de tiempo específico, mientras que la limitación ajusta
de forma dinámica el acceso en función de factores como la carga del servidor
o si la actividad se etiqueta como posiblemente maliciosa.
Otras tendencias y estándares clave que están dando forma al panorama de
las API incluyen un enfoque en la apertura y la interoperabilidad, sin sacrificar
la seguridad. Las empresas deben vigilar las tendencias, que incluyen:
Iniciativa OpenAPI. La OpenAPI Initiative, u OAS, es un consorcio de
organizaciones que trabajan en un lenguaje común para describir las API. Con
suerte, este formato estandarizado se sumará a una mejor documentación,
detección e integración.
Tokens web JSON. Otro esfuerzo de estándares abiertos, los JWT se están
convirtiendo en un método popular para la autenticación y autorización en API.
Proporcionan una forma segura para que las aplicaciones intercambien
información de identidad de usuario sin almacenar datos confidenciales en el
propio servidor de API.
OAuth 2.0. Debido a que la seguridad es tan crítica como la
estandarización, OAuth 2.0, el protocolo estándar del sector para la
autorización, se está adoptando ampliamente. El marco OAuth 2.0 permite a
las aplicaciones acceder a los datos de usuario en la plataforma de otra
aplicación sin necesidad de que los usuarios compartan sus contraseñas. Esto
da a las personas y empresas más control sobre sus datos.
OpenID Connect, u OIDC, se basa en OAuth 2.0 y permite a las aplicaciones
verificar la identidad de un usuario sin necesidad de credenciales de conexión
independientes para cada aplicación.
Por último, para las empresas que dependen en gran medida del sólido
rendimiento de la API, el análisis de API es una necesidad emergente. Al
supervisar y analizar de forma proactiva los patrones de uso de la API, el
departamento de TI puede identificar cuellos de botella en el rendimiento,
riesgos de seguridad y oportunidades de mejora. Busca un mánager de API que
ofrezca herramientas para recopilar y aumentar detalle en los datos de uso de
API. Medir qué API se están utilizando más puede ayudar a las organizaciones a
determinar dónde realizar inversiones. Por ejemplo, si las API de una solución
ERP obsoleta están utilizando más que las de CRM, puede tener sentido
priorizar la mejora o sustitución del ERP.
Cómo ayuda de Oracle
Oracle Cloud Infrastructure (OCI) proporciona un completo conjunto de
servicios para gestionar el ciclo de Vida de las API. Gracias a las herramientas
integradas, los equipos del desarrollador pueden colaborar fácilmente en la
Creación de Prototipos, la Realización de Pruebas y La Validación de las
diversas API. Oracle Cloud Infrastructure API Gateway proporciona integración,
aceleración, gobernanza y seguridad para sistemas basados en API y SOA, lo
cual permite a los equipos gestionar y entregar API web con total confianza.
Además, gracias a los planes de uso y las suscripciones, los operadores de API
podrán controlar y monetizar las API.
Una vez que un equipo de desarrollo entiende cómo funcionan las API, obtienen
información sobre las conexiones ocultas que impulsan muchas de las
aplicaciones y servicios que sus clientes y empleados utilizan todos los días.
Ahora, los desarrolladores pueden crear aplicaciones más rápido, mejor y por
menos aprovechando los datos y las funcionalidades expuestas a través de las
API en lugar de crear todo desde cero.
Las aplicaciones financieras son casos de uso importantes y exigentes
para las API. Pueden ayudar a los CIO a ayudar a los CFO a ofrecer
sistemas que satisfagan tanto a los empleados como a los clientes.
Estas son otras formas de ayudar a optimizar los procesos financieros
principales.
Preguntas frecuentes sobre API
¿Cuáles son los cuatro tipos de API?
Los cuatro tipos de API son públicos (cualquiera puede usarlos), privados
(desarrollados internamente dentro de una organización), socios (desarrollados
para trabajar entre software de organizaciones involucradas) y compuestos
(varios tipos de API utilizados juntos).
¿Qué es un ejemplo de una API en la vida real?
Un buen ejemplo de un proveedor público de API es la NASA, que proporciona
API para compartir datos de investigación, imágenes e información de
seguimiento de eventos. Estas API permiten a los desarrolladores obtener una
fuente de datos seleccionados de la NASA, como actualizaciones de Mars Rover
o detalles sobre eventos naturales rastreados por la NASA, como erupciones
volcánicas, e integrarlos en sus propias aplicaciones. Por ejemplo, una
aplicación meteorológica podría integrar las actualizaciones de Mars Rover en
una sección especial promovida como un feed "Live from Mars" para que los
usuarios lo vean.
¿Es fácil crear una API?
Escribir una API puede ser un proceso sencillo, especialmente para
desarrolladores experimentados. Las API se pueden codificar en casi cualquier
lenguaje de programación, y las arquitecturas existentes como REST
proporcionan directrices establecidas para trabajar con ellas. Una forma
sencilla de aprender desarrollo de API es realizar ingeniería inversa de las API
públicas de código abierto para ver cómo las han creado sus arquitectos.
¿Qué es la API de REST en términos simples?
REST, a veces denominado RESTful, significa "transferencia de estado
representacional" y es un protocolo estándar utilizado para el desarrollo de
servicios web. REST proporciona un juego de reglas y directrices para permitir
que diferentes aplicaciones se comuniquen a través de Internet de una manera
escalable y eficiente. REST define cómo las aplicaciones realizan solicitudes
(normalmente GET, PUT, POST y DELETE) a través de HTTP mediante HTML,
XLT, Python, JSON, PHP o texto sin formato sin depender del establecimiento de
un
.
La zona de emisor es la más fuertemente dopada de las 3, es la zona
encargada de “emitir” o inyectar portadores mayoritarios hacia la base. Huecos
en el caso de un transistor pnp o electrones en el caso del transistor pnp. La
base tiene un nivel de dopado netamente inferior al de la zona de emisor. Se
trata de una zona con un espesor muy inferior al de las capas exteriores. Su
misión es la de dejar pasar la mayor parte posible de portadores inyectados
por el emisor hacia el colector. La zona de colector, como su propio nombre
indica es la encargada de recoger o “colectar” los portadores que inyectados
por el emisor han sido capaces de atravesar la base. Es la zona con un nivel de
dopado inferior de las tres.
SÍMBOLOS Y CONVENIO DE SIGNOS Figura 4.2.- Sentidos de tensiones y
corrientes en el BJT. En la figura aparecen los símbolos que se utilizan para la
representación del transistor de unión bipolar. Para las corrientes se han
representado los sentidos reales de circulación de las mismas.