Icono del sitio IT&ライフハックブログ|学びと実践のためのアイデア集

[Informe de clase] Desarrollo de sistemas (3.º año) – Semana 42~Entrando en el mundo de las API: comprensión fundamental para conectarse a servicios externos de forma segura~

boy in green shirt

Photo by CDC on Pexels.com

[Informe de clase] Desarrollo de sistemas (3.º año) – Semana 42

~Entrando en el mundo de las API: comprensión fundamental para conectarse a servicios externos de forma segura~

A partir de la Semana 42, el plan de estudios de 3.º año comenzó oficialmente en serio.
Como introducción a esta etapa, nos enfocamos en qué son las API / por qué las usamos / cómo usarlas de forma segura,
dando el primer paso para extender las habilidades de diseño adquiridas en 1.º–2.º año a la integración con servicios externos.


■ Introducción del profesor: “Una API es una promesa con el mundo exterior”

Sr. Tanaka:
“Una API no es una caja mágica.
Es un conjunto de acuerdos sobre cómo la llamas, qué vuelve y qué ocurre cuando falla.”

El profesor primero puso en fila:

  • Las aplicaciones que hemos construido nosotros mismos
  • Servicios externos como el clima, mapas, traducción e IA generativa

y explicó que las API son diseños para cruzar fronteras.


■ Objetivos de hoy

  1. Comprender los conceptos básicos de las API (solicitud / respuesta)
  2. Poder leer la estructura de las API REST (URL, métodos, parámetros)
  3. Aprender los riesgos involucrados al usar API (fallos, límites, seguridad)
  4. Comprender dónde encajan las API dentro de los diseños aprendidos en 2.º año (DAO / Service)

■ Ejercicio ①: ¿Qué es una API? Pensar con ejemplos familiares

El profesor planteó preguntas usando apps cotidianas.

  • ¿De dónde obtiene una app del tiempo sus datos meteorológicos?
  • ¿Cómo muestra una app de mapas tu ubicación actual?
  • ¿Dónde realiza una app de traducción la conversión de idioma?

El alumnado reafirmó que “no todo está construido dentro de la app”.

Estudiante A: “Entonces nuestras apps también pueden tomar prestadas funciones del mundo exterior.”


■ Ejercicio ②: Leer la estructura básica de las API REST

Después, aprendimos a leer documentación de API.

Elementos básicos de una API REST

  • Endpoint: dónde acceder (URL)
  • Métodos HTTP: qué quieres hacer
    • GET (obtener)
    • POST (crear)
    • PUT / PATCH (actualizar)
    • DELETE (eliminar)
  • Parámetros: condiciones y valores de entrada
  • Respuesta: datos devueltos (a menudo JSON)

Ejemplo (para comprensión conceptual)

GET /weather?city=Tokyo
→ { "temp": 18, "condition": "Cloudy" }

Estudiante B: “¡Esto es parecido al concepto de DAO que aprendimos en 2.º año!”
→ Profesor: “Exacto. Piensa en una API como un DAO externo.”


■ Ejercicio ③: Practicar la lectura de respuestas de API (JSON)

Se entregaron datos JSON simples y el alumnado trabajó en identificar:

  • Qué información debe mostrarse en pantalla
  • Qué información debe guardarse
  • Qué información podría ser útil en el futuro
{
  "location": "Tokyo",
  "current": {
    "temp": 18,
    "humidity": 60,
    "wind": 3.2
  },
  "updated_at": "2026-01-08T10:00:00Z"
}

Estudiante C: “La idea de que no tenemos que usarlo todo es refrescante.”


■ Ejercicio ④: Precauciones clave al usar API (fallar es lo normal)

Aquí, el profesor enfatizó los puntos débiles de las API.

Cosas que siempre debes considerar al usar API

  • Pueden ocurrir errores de red
  • Las respuestas pueden ser lentas
  • Las especificaciones pueden cambiar
  • Hay límites de uso (rate limits)
  • Las claves de API son peligrosas si se filtran

Sr. Tanaka:
“El manejo de excepciones, el logging y las estrategias de fallback que aprendieron en 2.º año
son exactamente lo que necesitarán en la era de las API.”


■ Ejercicio ⑤: Encajar las API en nuestra propia arquitectura

En la pizarra, dibujamos la arquitectura del sistema que construimos en 2.º año
y añadimos una clase de API (ExternalService).

UI
 ↓
Service
 ↓
Cliente de API externa
 ↓
Servicio externo

Puntos clave:

  • Las llamadas a la API se hacen desde la capa Service
  • La UI nunca llama a las API directamente
  • La capa Service decide cómo manejar los fallos

Estudiante D: “Qué bueno que nuestro diseño de 2.º año funcione tal cual.”


■ Discusión: ¿Qué API te gustaría usar?

Por último, cada grupo discutió API que les gustaría probar.

  • API del clima
  • API de traducción
  • API de mapas / ubicación
  • API de noticias
  • API de IA generativa

Estudiante E: “Quiero usar IA generativa de una forma útil pero no peligrosa.”


■ Mensaje final del profesor

“Las API son tecnologías para tomar prestado poder del mundo exterior.
Por eso el diseño, la separación de responsabilidades y la preparación para fallos son tan importantes.

Las habilidades de diseño que adquirieron en 2.º año
son sus armas más fuertes para conectarse con el mundo exterior en 3.º año.”


■ Tarea (para la próxima semana)

  1. Elige una API que te interese e investiga brevemente:
    • Qué puede hacer
    • Qué entrada requiere
    • Qué datos devuelve
  2. Dibuja un diagrama mostrando dónde encaja esa API en tu sistema
  3. Enumera tres problemas que podrían ocurrir si la API falla

■ Adelanto de la próxima semana: llamar realmente a una API (práctica)

La próxima semana abordaremos nuestra primera implementación real de una API.
Enviarás solicitudes, recibirás respuestas
y experimentarás qué ocurre cuando aparecen errores.


La Semana 42 fue el momento
en que nuestros sistemas se pararon en la puerta de conectarse con el mundo exterior.
El alumnado comprendió tanto las posibilidades como las responsabilidades de las API,
dando un gran paso adelante hacia el aprendizaje a gran escala de 3.º año.

Salir de la versión móvil