[Informe de clase] Desarrollo de Sistemas (3.º año) — Semana 43
~Tu primera implementación de una API: experimentar solicitudes y respuestas~
En la Semana 43, basándonos en los conocimientos fundamentales sobre APIs de la semana pasada, realizamos un ejercicio práctico en el que el alumnado llamó realmente a una API externa.
Esta semana marcó el cambio de “leer” a “usar”, y los estudiantes tuvieron su primera sensación real de cómo es comunicarse con un servicio externo.
■ Introducción del profesor: “Hoy es el día en que escribirán código que hable con el mundo exterior.”
Sr. Tanaka: “Hoy, por primera vez, su código se comunicará con algo fuera de la escuela.
Lo importante no es solo que funcione, sino también ver qué ocurre cuando falla.”
El profesor reafirmó estas premisas para la práctica de hoy:
- Usaremos una clave de API solo para aprendizaje.
- Aunque llames a una API exactamente como dice la documentación, no siempre funcionará.
■ Objetivos de hoy
- Aprender a enviar solicitudes HTTP en código
- Recibir respuestas de la API (JSON) y extraer la información necesaria
- Observar respuestas de error e implementar manejo de excepciones
- Sentir cómo integrar llamadas a APIs dentro de la capa de Service
■ Ejercicio ①: Revisar de nuevo la documentación de la API
Primero, el alumnado revisó la API que cada uno investigó como tarea:
- Endpoint (URL)
- Método HTTP (GET / POST)
- Parámetros requeridos
- Respuesta de ejemplo
- Códigos de error (400 / 401 / 404 / 500, etc.)
Estudiante A: “Me di cuenta de que, si no lees bien la documentación, no entiendes por qué no funciona.”
El profesor enfatizó: “La mitad de implementar una API es leer la documentación.”
■ Ejercicio ②: Escribir una llamada simple a la API
Con Python, los estudiantes escribieron una llamada mínima a la API.
Ejemplo didáctico (comprensión conceptual)
import requests
url = "https://api.example.com/weather"
params = {"city": "Tokyo"}
response = requests.get(url, params=params, timeout=5)
response.raise_for_status() # convertir errores HTTP en excepciones
data = response.json()
print(data)
Puntos clave que se verificaron aquí:
- Si la URL y los parámetros se estaban enviando correctamente
- Códigos de estado (200 / 400 / 401, etc.)
- Que el JSON puede manejarse como un diccionario
Estudiante B: “¡Cuando lo imprimí, había muchísimos más datos de los que esperaba!”
■ Ejercicio ③: Extraer solo los datos necesarios
Luego, los estudiantes practicaron usar solo los campos necesarios de la respuesta completa.
temp = data["current"]["temp"]
condition = data["current"]["condition"]
print(f"Temperatura actual: {temp}°C / Clima: {condition}")
Consejo del profesor:
- Mostrar solo lo que necesitas ahora mismo
- Asumir que la estructura de la respuesta de la API podría cambiar algún día
Estudiante C: “Siento que poder leer JSON se conecta con habilidades de diseño.”
■ Ejercicio ④: Provocar errores a propósito
Las APIs no siempre funcionan.
Así que el alumnado probó intencionalmente casos como:
- Usar parámetros incorrectos
- Quitar la clave de API
- Especificar una URL que no existe
try:
response = requests.get(url, params=params, timeout=5)
response.raise_for_status()
except requests.exceptions.HTTPError as e:
print("Ocurrió un error HTTP")
except requests.exceptions.Timeout:
print("La solicitud agotó el tiempo de espera")
except Exception as e:
print("Error inesperado:", e)
Estudiante D: “Es importante que el programa no simplemente se caiga cuando ocurre un error.”
■ Ejercicio ⑤: Mover la llamada a la API a la capa de Service
Por último, aplicando los principios de diseño aprendidos en 2.º año, los estudiantes separaron la llamada a la API en una capa de Service (ExternalService).
UI
↓
WeatherService
↓
WeatherApiClient
↓
API externa
Puntos clave:
- No llamar a la API directamente desde la UI
- Tomar decisiones sobre el manejo de fallos dentro del Service
- Diseñar de modo que puedas cambiar la API más adelante si es necesario
Estudiante E: “¡No esperaba que las lecciones de diseño de 2.º año importaran tanto aquí!”
■ Aprendizajes de toda la clase
- Las APIs son “útiles”, pero también “inestables”.
- Sin manejo de errores, los programas fallan con facilidad.
- No necesitas usar todos los campos de la respuesta.
- Implementar después de diseñar reduce la confusión.
■ Nota final del profesor
“Hoy, su código tuvo su primera conversación con el mundo exterior.
Usar una API significa manejar algo que no puedes controlar por completo.
Por eso lo que aprendieron en 2.º año—separación de responsabilidades, manejo de excepciones y logging—empieza a importar de manera muy real.”
■ Tarea (para la próxima semana)
- Organizar la llamada a la API de hoy dentro de una clase Service y entregarla
- Escribir una explicación corta del comportamiento en caso de éxito vs. fallo
- Proponer un plan de contingencia para cuando no se pueda usar la API
■ Avance de la próxima semana: integrar la API en una app
La próxima semana, el alumnado integrará los datos obtenidos de la API en sus propios casos de uso de aplicación.
Este es el paso de “funciona” a “es útil”.
La Semana 43 fue un hito memorable:
por primera vez, los sistemas del alumnado se conectaron con el mundo fuera de la escuela.
Aunque hubo algo de confusión, experimentaron tanto el potencial como la dificultad de integrar una API—
y el aprendizaje de 3.º año ahora está realmente tomando impulso.