Avanzado
Nivel avanzado
En la sección básica aprendiste qué es una API, como invocarla y como se presentan los datos. Pero el trabajo real con APIs es más complejo. Los servidores tienen latencia. Las solicitudes fallan. Las respuestas cambian. El debugging es iterativo. Estos nueve laboratorios exponen los aspectos del trabajo con APIs que los tutoriales suelen omitir: rendimiento, fallas, confiabilidad e investigación. Cada uno utiliza las mismas APIs que ya conoces, pero en escenarios de mayor exigencia.
Comparativa de Latencia
Ejecuta las cuatro APIs al mismo tiempo. Observa cuál responde primero y por que.
El problema
Cada llamada API consume tiempo. Cuánto depende de la ubicación del servidor, el volumen de datos que devuelve, la carga actual del sistema y si ya existe una conexión establecida. Cuando invocas una API, esperas. Cuando invocas cuatro de forma simultánea, las diferencias se vuelven medibles. La latencia es invisible hasta que se cuantifica. Este laboratorio la hace visible.
Lo que observarás
- Tu API local (localhost) siempre es la más rápida porque no hay transmision por la red.
- Las APIs externas varian según su ubicación geográfica: Ciudad de Mexico, St. Louis, Washington DC tienen tiempos de respuesta distintos.
- El tamaño de la respuesta importa: 124 bytes de datos de mortalidad llegan antes que un dataset de tipo de cambio de 10KB.
- Ejecuta varias carreras y analiza la distribucion: la latencia no es constante, fluctua en cada medición.
Errores HTTP en Practica
Provoca cada tipo de error HTTP de forma intencional. Entiende que paso, por que, y cómo resolverlo.
El problema
Los tutoriales suelen mostrar el camino feliz: envías una solicitud, recibes un 200 OK, parseas el JSON. Pero en producción los errores son inevitables. Los servidores presentan fallas. Se activan los rate limits. La autenticación expira. Una URL tiene un typo. Si nunca has visto un 429 o un error CORS, la primera vez que aparezcan en producción podras perder horas de diagnóstico. Este laboratorio te permite provocar cada error de forma intencional, en un entorno controlado, para que los identifiques de inmediato cuándo ocurran en producción.
Lo que aprenderás
- Los errores 4xx indican un problema en la solicitud del cliente (bad request, URL incorrecta, autenticación ausente). Los errores 5xx indican una falla del servidor.
- CORS no es un HTTP status code. Es un mecanismo de seguridad del navegador que bloquea respuestas sin los headers apropiados.
- El rate limiting (429) protege a los servidores de la saturación. El header Retry-After indica cuándo reintentarlo.
- Los timeouts ocurren cuando el servidor tarda más de lo permitido. Siempre configura un timeout del lado del cliente y maneja el AbortError.
Historial de Llamadas
Cada llamada API que hiciste queda registrada. Inspecciona, compara y rastrea cambios entre respuestas.
El problema
El debugging real de APIs nunca es una sola solicitud. Envías una llamada, algo no cuadra, modificas un parámetro, envías de nuevo, comparas las dos respuestas, identificas la diferencia, ajustas y repites. Ese ciclo iterativo es la habilidad central del trabajo con APIs, pero rara vez se enseña. Este depurador registra cada llamada que realizas en la pagina y te permite inspeccionarlas, compararlas lado a lado, y ver exactamente que cambio entre dos respuestas.
Cómo utilizarlo
- Cada llamada API de la carrera y el playground se registra automaticamente aquí.
- Selecciona cualquier entrada para ver la URL completa de la solicitud y el cuerpo de la respuesta.
- Selecciona una segúnda entrada para abrir una vista de diferencias lado a lado que muestre cada cambio entre las dos respuestas.
- Utiliza esto para entender cómo modificar un parámetro (como age=45 vs age=65) transforma la estructura completa de la respuesta.
Realiza llamadas API en el playground o la carrera para verlas aquí.
Monitor de Salud API
Monitorea el estado de las cuatro APIs en tiempo real. Cuando una falla, eso se convierte en la lección.
El problema
Los tutoriales asumen que las APIs estan siempre disponibles. En la práctica, los servidores presentan interrupciónes, ventanas de mantenimiento y limites de capacidad. Si no has observado una caida de API antes, no sabras como manejarla en tu código cuándo ocurra. Este monitor hace ping a las cuatro APIs de forma continua para que puedas observar la disponibilidad, las tendencias de latencia y el comportamiento real durante una interrupción.
Lo que observarás
- Verde indica disponibilidad normal (responde en menos de 1 segúndo). Amarillo indica lentitud. Rojo indica interrupción.
- La línea de sparklines muestra la latencia de los últimos 30 pings. Los picos revelan inestabilidad.
- Tu API local debería mantenerse en verde. Las APIs externas pueden presentar estados amarillos o rojos de forma periodica.
- Por eso los sistemas en producción requieren reintentos automaticos, circuit breakers y fuentes de datos de respaldo.
Modo Inverso
Tienes la respuesta. Descubre que llamada API la genero.
El problema
En la práctica, muchas veces se parte de los datos, no de la documentación. Un colega te comparte una respuesta JSON y pregunta: de dónde proviene esto? Cuál API? Con qué parámetros? Este laboratorio invierte la dirección: te mostramos una respuesta, tú determinas qué llamada API la generó.
Lo que aprenderás
- Cómo identificar qué API produjo una respuesta observando los nombres de campos y la estructura.
- Cómo deducir los parámetros utilizados a partir de la respuesta (si age es 70, el parámetro fue age=70).
- Cómo distinguir la fuente: FRED devuelve "observations" con "date" y "value". Banxico devuelve "bmx.series" con "fecha" y "dato". World Bank devuelve arrays con "country" e "indicator".
- El ciclo de debugging: formar una hipótesis, probarla, comparar el resultado, ajustar, repetir.
Cómo funciona: un ejemplo rápido
Supongamos que ves esta respuesta: {"age": 70, "qx": 0.03498, "lx": 72039, "ex": 12.1}. Las pistas: tiene "age", "qx" (tasa de mortalidad) y "lx" (sobrevivientes). Esa estructura corresponde a la API de mortalidad. Entonces pruebas: /api/mortality?age=70. Si la respuesta coincide, lo resolviste. Busca nombres de campos, tipos de datos y rangos de valores para identificar la fuente.
Capas de una Respuesta HTTP
Explora que hay dentro de una respuesta HTTP, más alla del JSON.
El problema
Cuando llamas una API, ves datos JSON. Pero esos datos no aparecieron solos. Llegaron empaquetados dentro de algo llamado respuesta HTTP, que es como un sobre que lleva información adicional junto con los datos. Ese sobre viajó por internet siguiendo reglas llamadas protocolos. Este laboratorio te muestra cada capa de ese sobre, una por una.
Lo que observarás
- Capa 1 (Línea de estado): Muestra el método usado (GET), la URL solicitada y si fue exitosa (200 OK).
- Capa 2 (Headers): El sobre con metadatos. Content-Type te dice que los datos son JSON. Cache-Control te dice cuánto tiempo guardarlos.
- Capa 3 (Cuerpo sin procesar): El texto que llegó por la red, antes de que tu código lo procese.
- Cada capa cumple una función. Si alguna falla, la llamada API no funciona.
Términos clave (los verás dentro)
HTTP (HyperText Transfer Protocol): Las reglas que usan los navegadores y servidores para comúnicarse. Toda llamada API es una conversación HTTP.
Headers: Metadatos que acompañan cada respuesta. Te dicen cosas como: en qué formato vienen los datos? (Content-Type), puede el navegador guardarlos en caché? (Cache-Control), está este servidor permitiendo solicitudes desde mi sitio? (Access-Control / CORS).
Status Code: Un número que el servidor envía para decirte qué pasó. 200 significa éxito. 404 significa que no encontró el recurso. 500 significa que el servidor tuvo un error.
Response Body: Los datos que pediste. Normalmente en formato JSON. Es la parte que parseas y usas en tu código.
Realiza una llamada API y selecciona Anatomia para examinar su estructura interna
Cruce de Datos entre APIs
Conecta dos APIs, normaliza formatos y combina los resultados en una sola vista.
El problema
El análisis real casí nunca se basa en una sola fuente de datos. Se combinan tasas de interes con tipos de cambio, o datos de mortalidad con indicadores economicos. Pero cada API devuelve datos en un formato distinto, con diferentes convenciones de fecha y nombres de campo. Aprender a integrar datos de múltiples fuentes, normalizarlos y combinarlos es el puente entre invocar una API y realizar análisis de valor.
Lo que aprenderás
- Cómo ejecutar múltiples llamadas API en paralelo con Promise.all.
- Cómo normalizar distintos formatos de fecha (DD/MM/YYYY vs YYYY-MM-DD) en una clave común.
- Cómo combinar dos datasets a partir de una columna compartida (como año o fecha).
- Por qué la limpieza y normalizacion de datos demanda más esfuerzo que la llamada API en si.
How does US monetary policy correlate with the peso exchange rate?
Qué pasaria si...?
Ajusta una variable sobre datos reales y observa cómo cambia el resultado.
El problema
Las APIs te proporcionan hechos. El análisis se construye a partir de preguntas. Que ocurriria si la inflacion fuera 2% mayor? Que pasaria si la mortalidad disminuyera a la mitad? Que implicaria que el tipo de cambio se hubiera mantenido estable? Superponer un escenario hipotético sobre datos reales es lo que distingue obtener datos de analizar datos. Este entorno te permite modificar las variables y observar el impacto de forma inmediata.
Lo que aprenderás
- Cómo transformar datos de API del lado del cliente: escalar, desplazar y proyectar.
- Cómo cambios marginales en parámetros pueden generar diferencias significativas en los resultados.
- Por qué el análisis de escenarios es relevante para la gestion de riesgos, el pricing y las proyecciones actuariales.
- La diferencia entre obtener datos y razonar sobre datos.
What if life expectancy were higher or lower?
Diseña tu propia API
Define la estructura de un endpoint: parámetros, respuesta y reglas. Pruebala al instante.
El problema
Consumir APIs es una habilidad. Diseñarlas es otra. Cuando defines un endpoint debes decidir: qué método HTTP? Que estructura de URL? Que parámetros son obligatorios? Cómo se estructura la respuesta? Que errores son posibles? Esas decisiones determinan si una API es intuitiva o frustrante para quien la consume. Este simulador te permite tomar esas decisiones y verificar el resultado de inmediato.
Lo que aprenderás
- Cómo seleccionar entre GET y POST según la naturaleza de la operación del endpoint.
- Cómo nombrar parámetros con claridad y determinar cuáles son obligatorios vs opcionales.
- Cómo definir un schema de respuesta consistente y predecible.
- Por qué el buen diseño de API prioriza la experiencia del consumidor por encima de la conveniencia del servidor.
Use {{param_name}} to echo parameters in the response.