[Informe de Clase] Desarrollo de Sistemas (3.º Año) — Semana 44
Integración de Conexiones API en Casos de Uso: Convertir Datos Externos en “Funciones Útiles”
En la Semana 44, tomamos las llamadas a la API que implementamos la semana pasada y las incorporamos en casos de uso concretos para nuestra aplicación.
El tema fue ir más allá de “funciona” y convertirlo en una función significativa para los usuarios.
■ Introducción del Profesor: “Las APIs son ingredientes. Solo adquieren valor cuando las cocinas.”
Sr. Tanaka: “Los datos que se obtienen de una API a menudo son difíciles de usar tal cual.
Hoy diseñarán cuándo, dónde y cómo utilizarlos, y los traducirán a la experiencia del usuario.”
También repasó errores comunes en la integración de APIs:
- quedarse solo en mostrar los datos
- llamar a la API cada vez y hacer que la app sea lenta
- que la pantalla se rompa cuando ocurren errores
Esto reforzó la importancia del diseño.
■ Objetivos de Hoy
- Integrar de forma natural los datos de la API en los casos de uso existentes
- Realizar procesamiento, toma de decisiones y almacenamiento en caché en la capa de Servicio
- Asegurar que el caso de uso funcione incluso cuando la API falle
- Diseñar visualizaciones y mensajes amigables para el usuario
■ Ejercicio ①: Aclarar el Caso de Uso en el que se Usará la API
Cada grupo aclaró primero qué caso de uso utilizaría una API.
Ejemplos
- Sistema de biblioteca
- Buscar un libro → usar una API del clima para mostrar un “recordatorio de fecha de devolución en días lluviosos”
- Gestión de eventos escolares
- Lista de eventos → usar una API de mapas para mostrar la ubicación
- App de apoyo al aprendizaje
- Entrada en inglés → usar una API de traducción para mostrar texto de apoyo en japonés
Estudiante A: “Si no haces que la API sea la ‘protagonista’, la app se siente más natural.”
■ Ejercicio ②: “Procesar” los Datos de la API en la Capa de Servicio
En lugar de pasar las respuestas crudas de la API directamente a la UI, dimos formato a los datos con la forma necesaria en la capa de Servicio.
Ejemplo: Servicio de API del Clima (Conceptual)
def get_weather_hint(self, city):
weather = self.weather_api.fetch(city)
if weather["condition"] == "Rain":
return "Se pronostica lluvia hoy. Por favor, tenga en cuenta la fecha de devolución."
else:
return None
Puntos clave:
- La UI solo decide si mostrar algo o no
- Los cambios en la especificación de la API no afectan directamente a la UI
- Los datos se interpretan en el contexto del caso de uso
Estudiante B: “Se siente como si estuviéramos convirtiendo datos crudos de la API en un mensaje significativo.”
■ Ejercicio ③: Reducir Llamadas con Caché
Se asume que las APIs son:
- lentas
- con límites de uso
Por ello, introdujimos una caché simple.
Imagen orientada al aprendizaje
- Reutilizar el clima de la misma ciudad durante 10 minutos
- Gestionar la caché en la capa de Servicio
- Confirmar el número de llamadas a la API mediante logs
Estudiante C: “¡Después de añadir la caché, se sintió más rápido de inmediato!”
El Sr. Tanaka también compartió un punto práctico:
“El almacenamiento en caché es un equilibrio entre precisión y velocidad.”
■ Ejercicio ④: No Detener el Caso de Uso Cuando la API Falla
A continuación, diseñamos el comportamiento cuando la API no está disponible.
Política de implementación
- Incluso si la API falla, la función principal continúa
- Solo se oculta la información complementaria (clima/traducción, etc.)
- Mostrar un aviso breve y sencillo a los usuarios
try:
hint = weather_service.get_weather_hint(city)
except Exception:
hint = None
Ejemplo de visualización en la UI:
- “La información meteorológica no está disponible en este momento.”
Estudiante D: “Usar APIs para funciones ‘agradables de tener’ es más seguro.”
■ Ejercicio ⑤: Integrar en la UI y Ajustar la Visualización
Finalmente, integramos de forma natural la información derivada de la API en la UI.
- Mantenerla como información de apoyo, no demasiado prominente
- Ajustar la “importancia” mediante color y ubicación
- Mantener los mensajes de error discretos
Estudiante E: “Aunque la app use APIs, idealmente los usuarios no deberían notarlo.”
■ Puesta en Común de Toda la Clase: Lo que Funcionó Bien
Ejemplos de enfoques exitosos compartidos en clase:
- Convertir los resultados de la API en frases para mejorar la UX
- Comportamiento estable mediante caché + alternativas
- Centralizar las decisiones relacionadas con la API en la capa de Servicio
- Seguimiento de las tasas de fallos de la API mediante logs
■ Comentario Final del Profesor
“El objetivo de la integración de APIs no es usar una API—
es mejorar la experiencia del usuario.
Diseñar:
- dónde usarla, y
- qué hacer cuando no está disponible,
es exactamente como se trabaja en el mundo real.”
■ Tarea (Para la Próxima Semana)
- Crear una descripción de caso de uso de una página que incluya la API
- Preparar capturas de pantalla tanto para éxito de la API como para fallo de la API
- Si añadieras una API más, proponer dónde la integrarías
■ Adelanto de la Próxima Semana: Múltiples APIs y la Idea de la Asincronía
La próxima semana aprenderemos:
- consideraciones de diseño al usar múltiples APIs al mismo tiempo, y
- cómo manejar el tiempo de espera y los fallos—pensamiento central para el procesamiento asíncrono
La Semana 44 marcó el paso de la integración de APIs de una “demo técnica” a una “función práctica”.
Los estudiantes fueron desarrollando de manera constante las habilidades para usar servicios externos de forma inteligente y segura mediante un buen diseño.