La misión
Elige UNA API pública con plan gratuito y construye su interfaz bonita y útil: clima para ciudades (con buscador geocodificado), mapas (punto a punto con distancia y tiempo), o cotizaciones (USD/MXN con gráfico histórico). Tres reglas de ingeniería que definen el proyecto: la clave del servicio vive en TU servidor (la señal 1 del detective aplicada a APIs), las respuestas se cachéan según su vida útil real (el clima de una hora no cambia cada segundo), y los cinco estados del servicio se muestran al usuario sin dramas ni pantallazos de error crudos.
La ruta, seis tiempos
Ruta del proyecto 4
- La documentación oficial, LEÍDA POR TI, no por el chat: qué endpoints hay, qué parámetros piden, qué devuelven y qué límites tiene el plan gratis. Elige a propósito un endpoint con un campo interesante (el pronóstico a 5 días, la matriz de distancias): la riqueza de tu app sale de lo que la API realmente ofrece.
El prompt del proxy con caché
Proyecto 4: integracion con la API de [SERVICIO]. Documentacion real: [pega ENDPOINT, parametros\ny respuesta de ejemplo]. La clave va en variable de entorno SERVICIO_KEY: jamas en el\nfrontend ni en el repo.\n\nImplementa en mi backend (stack del maestro) el endpoint proxy /app/datos?ciudad=X:\n1. llama a la API real con SERVICIO_KEY desde entorno\n2. CACHE: si tengo respuesta de esa ciudad con menos de [TTL segun el dato], la devuelvo\n de la cache sin llamar; si ya vencio, llamo y actualizo. Reporta X-Cache: HIT/MISS.\n3. ESTADOS: respuesta normal | sin datos (la API devolvio vacio: lo digo, NO invento)\n | error de la API (5xx: mensaje amable, reintento una vez) | SIN CUOTA (429 del\n proveedor: le digo al usuario que espere, y NO reintento en bucle)\n | la API tardo demasiado (timeout 5 s: cortamos y avisamos)\n4. el log registra ciudad, estado y duracion. Nunca la clave, nunca el cuerpo completo.\n\nPruebas automatizadas por cada estado (con la API simulada: mocks). Frontend despues:\nesta capa se aprueba sola primero.Qué entrega este proyecto
| Entregable | Barra alta de este proyecto |
|---|---|
| ESPECIFICACION.md | el contrato de la API externa copiado de su documentación OFICIAL (con enlace), y los cinco estados definidos con su copy |
| HALLAZGOS.md | el prompt de la IA que usó un parámetro que la API real no tiene (¿verificado contra la documentación o "plausible"?) |
| PRUEBAS.md | los cinco estados provocados uno por uno: vacío, error, cuota agotada, lento y normal |
| App publicada | funciona con la red cortada a mitad, sin filtrar la clave, y sin gastar la cuota en cada clic |
Prueba
Tu app muestra el clima y la IA puso la clave del proveedor en el JavaScript del frontend «porque así responde más directo». ¿Qué dos principios rompió?
La API real devolvió una lista vacía para una ciudad: el prompt correcto para la IA es «asegúrate de que nunca devuelva vacío, compleméntalo con la ciudad más cercana».
Paso uno y sin atajos: abre la documentación OFICIAL de tu API elegida y anota a mano los tres datos del contrato (endpoint, parámetros, límite del plan gratis) antes de hablar con la IA. Cuando ella genere el código, tu primera pasada de revisión es ctrl-f contra lo que copiaste, no contra su memoria.