Laboratorio ejecutable · Bloque 1
EX-B1-02
El código de estado del incidente
Una API documental responde siempre con `200`, incluso cuando el consumidor no puede continuar. El equipo ya acordó usar `422` para datos JSON bien formados que incumplen el schema y `503` para dependencias temporalmente no disponibles; debes aplicar esa política a seis resultados concretos.
Cómo abordarla
Observa el fundamento construyendo una API
Descarga el starter, predice un resultado, ejecuta, modifica la API y vuelve a observar. La explicación breve acompaña al código; no lo sustituye.
Abrir laboratorio de código
1. Descarga y arranca
- Starter ejecutable de estados HTTPSeis operaciones incompletas y tests de contrato que obligan a implementar cada resultado.
- Matriz de incidentesPlantilla breve para status, evidencia y acción del consumidor.
2. Escribe y prueba
- Ejecuta el baseline y relaciona cada fallo con una operación concreta de la API.
- Implementa los seis resultados sin devolver `200` como envoltorio universal; añade `Location` a la creación y un body de error estable.
- Escribe al menos dos tests propios: uno que demuestre 409 por referencia duplicada y otro que demuestre 503 sin convertirlo en 500.
- Arranca la API y conserva una respuesta 2xx y otra 4xx/5xx obtenidas por HTTP.
3. Demuestra el comportamiento
- `app.py` con seis resultados contractuales y tests verdes.
- Salida de pytest y dos respuestas HTTP capturadas.
- Tabla breve status → condición → acción posible del consumidor.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
Antes de ejecutar, ¿qué dos rutas del starter crees que aún devuelven un status incorrecto y qué test lo hará visible?
Información que necesitas
Política de la API
- JSON bien formado que incumple el schema: 422.
- Dependencia temporalmente no disponible: 503.
Resultados observados
A. GET /documents devuelve 18 elementos.
B. POST /records crea REC-204 y emite Location: /records/REC-204.
C. PATCH /records/REC-204 recibe {"closed_at":"tomorrow"}; el schema exige date-time ISO 8601.
D. GET /records/REC-999 usa un id válido que no existe.
E. POST /records recibe external_reference=REF-77, ya asociada a otro registro.
F. Una petición válida no termina porque la base de datos está temporalmente fuera de servicio.Comprueba estas tres cosas
- Clasifica primero cada situación como éxito, problema del cliente o fallo del servidor.
- Elige un código concreto para A–F y justifícalo con una frase.
- Justifica cada elección con el hecho observable que la determina.
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista 1 · Decide primero la responsabilidad
- Pregunta si una petición idéntica podría funcionar sin cambiar nada del servidor.
- Después concreta el código dentro de la familia elegida.
Pista 2 · Conflicto no significa sintaxis inválida
- Una representación puede estar bien formada y aun así chocar con el estado actual del sistema.
Profundización opcional
Implementar respuestas 200, 201, 404, 409, 422 y 503 en una API pequeña y comprobar qué puede hacer el consumidor en cada caso.
Contexto adicional
- No basta con escribir un número: cada elección debe relacionarse con lo que ocurrió y con la acción que puede tomar el cliente.
- No inventes supuestos alternativos: la política de `422` y `503` forma parte del enunciado.
Cómo revisar tu respuesta
- No se utiliza 200 como respuesta universal.
- Los errores provocados por datos del cliente no se clasifican como fallos internos.
- La creación se distingue de una lectura satisfactoria cuando el servidor crea un recurso identificable.
- La justificación describe comportamiento observable y no detalles de implementación.
- La suite se ejecuta desde limpio y cada status se produce mediante una rama real del endpoint.
Evidencia, revisión y reinicio
- Implementación de seis resultados HTTP y suite de contrato ejecutada.
- Una petición positiva y una negativa añadidas por el alumno.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Eliminar el workspace temporal y volver a extraer el ZIP.