Bienvenidos a otro episodio de Microsoft Knowledge Nuggets. Soy su anfitrión Mirko Pit. El tema de hoy es algo que casi todos han oído mencionar, pero pocos entienden realmente. Las API. Probablemente hayan escuchado el término bastante seguido. Es una de esas palabras técnicas que la gente usa para sonar como si supieran de lo que hablan. Pero aquí está la cuestión. Las APIs son realmente simples. Son solo una forma en que un software se comunica con otro. Tu teléfono solicita datos 11. El servidor los envía de vuelta. Eso es una llamada a un API. Ahora imagina que tienes 20 API, o 50, o 100. Cada una puede usar una autenticación. Límites de tasa. Y documentación diferentes, si es que tiene. De repente, lo que empezó como una conversación simple entre dos aplicaciones se convierte en un caos total. Sin un administrador central, cada equipo reinventa la rueda. Un equipo crea su propio sistema de autenticación.

Otro construye su propio registro. Surgen brechas de seguridad. Los desarrolladores se confunden sobre qué API hace qué. Y no tienes una visión única de lo que sucede en todo tu sistema. Azure API Management es sobre esto. Te ofrece un centro de control. Piénsalo como una torre de control de tráfico aéreo para tus APIs. Al final de este episodio entenderás qué es realmente, por qué es importante y cómo encajan todas las piezas. Toma tu café y comencemos. El problema, demasiadas APIs sin control. Esta es la realidad del software moderno. Hace 10 años probablemente tenías una gran aplicación. Un monolito. Una base de datos. Una API simple. Hoy, esa misma aplicación podría estar dividida en docenas de microservicios. Cada servicio maneja una cosa. Cuentas de usuario, pagos, inventarios, notificaciones y cada uno expone su propia API. De repente tienes 10, 50 o 100 puntos de entrada distintos a tu sistema.

Ahora, imagina que eres un desarrollador intentando construir algo que uses taza. Necesitas encontrar cada una y descubrir la autenticación para tu hacer. Algunos usan claves API, otras OAuth. Algunos no usan nada en absoluto. Necesitas manejar el límite de tasa manualmente o arriesgarte a ser bloqueado. Necesitas comprender el formato de datos que espera cada uno. Es agotador. Empeora desde la perspectiva operativa. Sin una puerta de enlace central, cada equipo debe agregar seguridad y registro a su propio servicio manualmente. Algunos equipos lo hacen bien, otros olvidan registrar errores. Algunos ni siquiera validan las entradas. Consistente y propenso a errores. Una pesadilla de seguridad esperando ocurrir. El cumplimiento se vuelve casi imposible. Necesitas demostrar quién accedió a KeyCoin. Buena suerte teniendo pistas de auditoría de 20 servicios diferentes, cada uno con su propio formato de registro.

Necesitas ver cuántas llamadas a la API manejó tu sistema el mes pasado. Estás uniendo métricas de una docena de paneles diferentes. Y tal problema. A medida que escalas esto no solo es molesto. Prácticamente cerramos. No puedes agregar más desarrolladores, más servicios ni más clientes sin un punto de control central. Piénsalo como si fuera un edificio. Imagina que cada habitación de una cerradera era diferente. No hay recepción ni directorio. Los visitantes deambulan tratando de encontrar la puerta correcta frustrándose y finalmente rindiéndose. Un caos total. Este es el problema que la gestión de APIs fue diseñada para resolver. Es Azure API Management la torre de control. Entonces, ¿qué es exactamente Azure API Management? Aquí está la definición más sencilla. Es un servicio administrado que se ubica entre tus APIs de backend y las aplicaciones, sitios web, dispositivos y socios que las consumen.

Pero escucha, no es solo un proxy. Un proxy reenvía el tráfico. Eso es todo. Azure API Management cubre el ciclo de vida completo de tus APIs. Públicalas, asegúralas, monitorealas y finalmente retíralas. Centro completo. Desglosemos esto en tres componentes principales. El primero es la puerta de enlace. Esta es la puerta de entrada. Cada solicitud entrante de una aplicación o sitio web llega primero a la puerta de enlace, nunca directamente a tu backend. La puerta de enlace procesa la solicitud, aplica las políticas que estableciste, recopila métricas y luego la reenvía al servicio de backend correcto. Piénsalo como un agente de tránsito. Luego está el plano de administración. Aquí es donde defines todo. Tus APIs, tus políticas, tus productos, tu inscripción. Lo haces a través del portal de Azure, la línea de comandos, infraestructura como código, como Bicep o Terraform. Es la sala de control donde configuras cómo funciona todo.

Y luego el portal para desarrollador. Es un sitio de autoservicio donde los desarrolladores internos y externos pueden descubrir tus APIs, leer documentación, obtener claves de suscripción e incluso probar llamadas a la API directamente en su navegador. Ya no hay que enviar archivos PDF por correo de un lado. Aquí hay una analogía que ayuda. Piense en un aeropuerto modelo. La puerta de enlaces de aterrizar. Cada avión aterriza allí primero. El plano de administración y la torre de control. Dirige el tráfico, establece reglas y monitorea todo. El portal para desarrolladores es el panel de información. Los pilotos lo consultan antes de volar y pueden encontrar toda la información que necesiten sin hablar con nadie. Ahora enfoquemos en la puerta de enlace. Esa es la parte con la que tus aplicaciones realmente hablan y dónde ocurre la verdadera mai. La puerta de enlace, la puerta de entrada de tu API.

Hablemos de la puerta de enlace porque es la parte con la que tus aplicaciones realmente se comunican. Cada solicitud de una aplicación móvil, sitio web o dispositivo IoT llega primero al gateway. Nunca directamente a tu backend. Ese es el punto principal. El gateway se coloca al frente y actúa como un punto de entrada único. El gateway puede aplicar políticas antes de reenviar la solicitud. Las políticas son reglas que escribes en XML o JSON como limitación de tasa, filtro de IP, reescritura de encabezados y comprobaciones de autenticación. Todo esto sin cambiar una sola línea de código de tu backend. Aquí tienes un ejemplo concreto. Digamos que tienes un nivel gratuito y uno premium para tu app. Con una política puedes limitar a los usuarios gratuitos a 5 solicitudes por minuto, mientras que los premium tienen 100. Tu backend nunca nota la diferencia. Simplemente procesa las solicitudes.

El gateway se encarga de aplicación. El gateway también maneja el almacenamiento en Calle. Si se solicitan datos repetidamente, como una lista de productos que rara vez cambia, el gateway puede guardar la respuesta y servirla directamente. No hay necesidad de molestar a tu backend, lo que significa respuestas más rápidas y menos carga en tus servidores. También puede transformar datos. Tu backend podría devolver XML, pero tu aplicación móvil espera JSON. El gateway puede convertirlo a vuelo. Tu backend no necesita cambiar y tu aplicación tampoco necesita cambios. El gateway se encarga de la traducción. Y registra cada llamada, cada solicitud, cada respuesta y cada error. Obtienes una pista de auditoría completa de quién llamó a qué, cuándo y qué sucedió. Eso por sí solo justifica la inversión por el cumplimiento normativo. Si tienes una audiencia global, puedes desplegar el gateway en múltiples regiones.

El tráfico se enruta automáticamente a la más cercana, lo que reduce la latencia y mejora la experiencia. Una cosa más, el gateway oculta la URL real de tu backend. Los clientes solo ven la dirección del gateway. Tus servidores de backend permanecen ocultos de internet. Eso es una gran victoria de seguridad desde el primer momento. Políticas, el motor que controla todo. Entonces, ¿qué hay de esas políticas que menciono? Son el motor que hace que Appim sea verdaderamente potente. Una política modifica el comportamiento de la solicitud o respuesta sin que tengas que tocar tu código de backend. Piensa en ello como un envoltorio alrededor de tu app. A medida que el tráfico fluye, puede agregar, eliminar o cambiar cosas automáticamente. Las políticas pueden ejecutarse en cuatro puntos del ciclo de vida de la solicitud. De entrada, en el camino, antes de que la solicitud llegue a tu backend. De salida, en el retorno, antes de que la respuesta llegue al cliente.

Backend, justo antes de que la solicitud llegue a tu servicio. Y ante errores, cuando algo falla, las tareas comunes de entrada incluyen validar tokens JWT para verificar la identidad, comprobar claves de API, reescribir URL y restringir por dirección IP. Todo esto sucede antes de que su backend vea una sola solicitud. Para la salida, puede transformar el cuerpo de respuesta. Busca y reemplazar texto, eliminar campos confidenciales, cambiar formatos. Puede almacenar respuestas en caché para que las solicitudes repetidas no lleguen a su backend. Incluso puede eliminar encabezados que revelen información interna. Aquí un ejemplo concreto. Suponga que su API devuelve descripciones de productos con la palabra azul en todas partes. Quiere cambiar la marca y usar amarillo en su lugar. En lugar de cambiar el código de su backend, añade una política de salida. Buscar azul, reemplazar con amarillo y listo.

Su backend nunca cambia. Las políticas de limitación de tasa y cuotas protegen su backend de abuso. Si la aplicación de alguien falla y empieza a bombardear su API 10.000 veces por segundo, la política interviene y dice más despacio. Su backend permanece saludable. Necesita lógica avanzada. Puede escribir expresiones y ya personalizadas dentro de las políticas. Se compilan para obtener mejor rendimiento. Por lo tanto, no hay costo de tiempo de ejecución. Puede consultar roles de usuario, calcular límites de tasa dinámicos, o transformar respuestas condicionalmente según los encabezados. La idea principal es esta. Las políticas le permiten controlar cómo se comportan sus APIs sin tocar el código que las ejecuta. Eso significa cambios más rápidos, menos implementaciones y menos riesgo. Productos y suscripciones. Empaquetando API para los consumidores. Ahora sus APIs están definidas. Las políticas implementadas y la portada enlace funcionan a la perfección.

Pero ¿cómo otorga acceso a diferentes clientes y a diferentes cosas? Ahí es donde entran los productos y la suscripción. En Apping, usted agrupa las APIs en algo llamado producto. Piénselo como un paquete. Podría tener un producto de nivel gratuito que solo incluya sus APIs básicas. Quizás solo acceso de lectura. Y luego un producto premium que incluya todo. Incluya sus operaciones de escritura y puntos finales de administración. Los desarrolladores no se suscriben a APIs individuales. Se suscriben a un producto. Cuando se suscriben, obtienen una clave de suscripción. En realidad, dos claves. Para que pueda rotar una sin tiempo de inactividad. Esa clave es su pase para usar cualquier API de ese producto. Te controla cómo funciona la suscripción. Los productos pueden requerir evaluación. Te acepta manualmente cada suscriptor o pueden estar abiertos al autoservicio. Cualquiera se registra y obtiene acceso inmediato.

También puede incluir términos legales que los usuarios deben aceptar antes de suscribirse. Eso es importante si sus APIs manejan datos confidenciales. Así es como usted monetiza las apps. Un producto gratuito con límites de tasa bajo. 5 llamadas por minuto. Un producto pago con límites más altos o más puntos finales. 100 llamadas por minuto. Además de acceso a funciones premium. A su backend no le importa. La puerta de enlace aplica los límites según el producto al que se ha suscrito el llamador. Hay un ejemplo real. Imagínate que estás creando una aplicación para conferencia. Creas un producto para asistentes con APIs para el cronograma de sesiones, biografías de oradores y mapas del lugar. Luego un producto para patrocinadores que también incluye APIs de generación de leads. Los patrocinadores pueden escanear las acreditaciones de los asistentes y obtener información de contenido. Un backend, productos diferentes, niveles de acceso distinto.

Esas dos claves de suscripción están diseñadas para la rotación. Si una clave se ve comprometida, generas una nueva. La segunda clave te permite cambiarse y interrumpir el servicio. Genera una clave nueva, actualiza tu aplicación y revoca la anterior. Sin interrupción. El portal para desarrolladores. Autoservicio para consumidores de Apple. Entonces ya configuraste tus productos de Apple. Ahora los desarrolladores necesitan un control. Ese es el trabajo del portal para desarrolladores. El portal para desarrolladores es un sitio web integrado en cada instancia de API. Los desarrolladores lo usan para explorar tus APIs, leer la documentación y probar endpoints de forma interactiva directamente en su navegador. No se requiere configuración ni correos de ahí vuelta. Sin embargo, hay algo importante. Estás sin publicar de forma predetermina. Cuando creas tu instancia de APM por primera vez, el portal existe, pero nadie puede verlo.

Primero debes personalizarlo y publicarlo. Eso es intencional. No querrás mostrar un portal a medio terminar el mundo. Puedes personalizar colores de marca, logotipos e incluso insertar contenido de WordPress para un blog junto a tus documentos de API. Es totalmente personalizable para que coincida con la imagen y el estilo de Android. Valor real es el autoservicio. Los desarrolladores se registran, obtienen sus claves de suscripción automáticamente y comienzan a llamar a las APIs de inmediato. Sin correos manuales, sin espera de aprobación, sin tiquete de soporte, preguntando cómo obtener una clave. Lo hacen ellos mismos, lo que reduce significativamente tu carga de soporte. También puedes publicar registros de cambios y notas de versión. Cuando actualizas una API, los desarrolladores lo ven en el portal sin sorpresas. El acceso puede ser público para cualquiera con la URL o puedes restringirlo a usuarios de tu inquilino de Entry ID para que solo las personas de tu organización puedan explorar.

Ambas opciones existen para diferentes casos de uso. El portal para desarrolladores es lo que convierte a tu gestión de API en una plataforma real. Piénsalo como la víctima para tus apps. Sin él, los desarrolladores tienen que buscar en documentos y preguntar por ahí. Con él encuentran lo que necesitan y comienzan a construir. Seguridad, autenticación, autorización y secretos. Todo este poder es inútil si la seguridad no está bien blindada. Entonces, hablemos de cómo API maneja la identidad, el acceso y los secretos. API admite múltiples métodos de autenticación. El más simple son las claves de suscripción de las que hablamos antes. Pero, para sistemas de producción, se requiere algo más robusto como OAuth 2.0, tokens JBRID, certificados de cliente o filtrado de IP. Se aplica en estas capas según qué tan sensible sea su API. Para producción, la mejor práctica es utilizar OAuth 2.0 con Entry ID.

Así es como funciona. La aplicación cliente obtiene un token de Entry ID y lo envía con la solicitud a la API. API valida el token comprobando la firma, el emisor, la audiencia y la expiración. Si es válido, API reenvía la solicitud a su backend, incluyendo el token. Su backend confía en él porque API ya lo verificó, así que no necesita revalidarlo. Es una carga menos que cada servicio de gestión. Ahora, hablemos sobre los secretos. Claves de API cadenas de conexión certificados. No querrá tenerlos codificados en archivos de política o control de fuente. API cuenta con una función llamada Valores con Nombre. Te almacena los secretos centralmente en API y los referencia por nombre en sus políticas. El valor real nunca aparece en el código de su política. Mejor aún, puede conectar valores con nombre Azure Key Vault. Los secretos permanecen cifrados en Key Vault y API los obtiene en tiempo de ejecución.

Nadie, ni siquiera su equipo de DevOps, ve el valor secreto real. Cuando necesita rotar una clave, la actualiza en Key Vault y API detecta el cambio automáticamente. API también admite identidades administradas. Esto permite que API se autentique en otros servicios de Azure, como Key Vault o una API de backends, sin almacenar credenciales. Azure gestiona la identidad. Usted solo debe otorgar los permisos. Y para el aislamiento de red, puede implementar API dentro de una red virtual. Esa es la capa premium. O usar Azure Front Door, el punto es que sus servicios de backends nunca necesitan estar expuestos directamente a Internet. API es lo único que el mundo exterior puede ver. Este enfoque por capas construye una defensa en profundidad. Autenticación en la puerta de enlace. Secretos en un almacén. Aislamiento de red alrededor de sus backends. Cada capa fortalece a 100. Niveles de precios.

¿Cuál es el adecuado para los datos? Entonces, ¿cuánto cuesta? Revisemos los niveles. El nivel de consumo. Pague por llamada lápiz sin costo mensual fijo. Perfecto para volúmenes bajos o cargas de trabajo intermitente, como cuando está creando prototipo. Si aún no está seguro de lo que necesita, comience aquí. El nivel de desarrollador le ofrece un costo mensual fijo bajo de unos 50 dólares. Con punto completo de fusión es percinesera. Ideal para entornos de desarrollo y prueba. Obtiene todo lo que tiene en la versión premium, pero no puede usarlo para producir. El nivel básico es el nivel inicial propio. Menor rendimiento sin soporte de red virtual, pero obtiene una SLA real. Bueno, para herramientas internas o proyectos pequeños donde la red privada no es crítica. La mayoría de las empresas eligen el nivel estándar. Incluye soporte para red virtual, un SLA del 99.5% y buen rendimiento.

Si ejecuta apicríticas para el negocio, probablemente aquí es donde se establecerá. El nivel premium es para empresas globales que necesitan máxima fiabilidad y redes privadas. Implementación multiregional porta de enlace autohospedada SLA del 99.99% y inyección completa de red virtual. Comienza alrededor de 2.600 al mes por unidad. Microsoft también introdujo los niveles V2, básico V2, estándar V2 y premium V2. Simplifican los precios con cuotas de solicitudes incluidas y cargos por cada millón excedente. En lugar de rastrear múltiples medidores, obtiene un volumen claro de solicitudes y paga el uso adicional en incrementos simples. Es decir, ¿cómo puede elegir? Comience con el desarrollador proper. Pase el estándar para la producción. Opte por el premium si necesita escala global o redes privadas. Y recuerde, siempre puede migrar de nivel más tarde. Empiece poco a poco y crezca en sus necesidades.

Esto es lo que cubrimos. La gestión de API toma el caos de muchas API y las reúne en un centro de control para puertas de enlace, política, seguridad y experiencia del desarrollador. La conclusión clave es que es más que un proxy. Piense en ello como el cerebro y el sistema nervioso de su ecosistema de app. Sin esto, cada equipo construye su propia autenticación, registro de tasa. Termina con inconsistencia, brechas de seguridad y sin una visión única de lo que sucede. Con esto, obtiene consistencia, seguridad y escalabilidad sin reinventar la rueda para cada servicio. Aquí hay un ejercicio simple. Piensa en una API que actualmente expone directamente. Quizás un punto de conexión de función o un servicio de aplicar. ¿Cómo cambiaría su postura de seguridad y su capacidad para monitorear el uso al colocar la gestión de API al frente? Incluso solo pensar en ese ejercicio le mostrará el valor.

Siguiente paso, suscríbase al canal. En episodios futuros, le mostraremos cómo importar una API, aplicar su primera política y monitorear el uso en tiempo real. Pasará de la teoría a la práctica. Si le resultó útil, compártelo con alguien que esté creando una aplicación. Le ahorra meses de dolor de cabeza. Gracias por su atención.