Lección 25 de 25 · Lectura y práctica
Quiz Final: Evaluación del Proyecto Integrador
Prepara la evaluación final de tu API Go con un caso de contrato HTTP, pruebas de autorización y una revisión del proyecto integrador.
Del concepto a la práctica
Taller de esta lección
La revisión final sigue un pedido completo de la librería y contrasta su resultado con la reserva de stock. El contrato debe explicar fallos y repeticiones además del caso válido; una captura del pedido no demuestra que la reserva se conserve correctamente.
Ejemplo resuelto
Datos iniciales: producto7 a 1250 céntimos EUR, stock5; usuario u1 autorizado, sin pedidos ni reservas. Envía cantidad2, clave aula-u1-001 y correlación req-42. El precio viene del catálogo y el total es 2500 céntimos. Tras la confirmación queda un pedido y stock3. Repetir el mismo payload y clave devuelve el pedido previo sin otra reserva.
| Caso | Resultado del contrato |
|---|---|
| Sin credencial válida | 401; ningún pedido ni reserva |
| Cantidad cero | 400; ningún pedido ni reserva |
| Pedido válido de dos unidades | 201; total2500, stock3 |
| Misma clave y payload | respuesta del pedido previo; stock3 |
| Misma clave y cantidad distinta | 409; sin nueva mutación |
| Dependencia no disponible | error controlado; estado pendiente o sin reserva documentado |
Pruébalo
Usa datos de laboratorio nuevos y registra stock/pedidos antes de cada caso.
Ejecuta los cinco primeros casos con la política declarada.
Simula un timeout y consulta el estado por la misma clave antes de reintentar.
Comprueba correlación, contadores por endpoint y persistencia tras reiniciar el laboratorio.
Error frecuente: creer que abortar la conexión revierte una mutación remota. La petición puede haber llegado; idempotencia y recuperación deben manejar esa incertidumbre sin crear un segundo pedido.
Comprueba tu resultado
El caso válido y su repetición conservan un único pedido y una única reserva de2. Una solicitud inválida no altera esos datos. Explica cómo productos evita una reserva superior al stock con pedidos concurrentes y qué evidencia distingue un fallo de proceso de un estado de negocio pendiente.
Mapa de prácticaEl navegador envía una solicitud a la API. El servidor valida la operación y consulta los datos; después devuelve una respuesta que el navegador puede mostrar. La base de datos se comunica con el servidor y no directamente con el navegador.
Ver la infografía en tamaño completo ↗Fuentes para profundizar
Tipo de lección: Quiz
Evaluacion del modulo
Responde estas preguntas para comprobar que puedes aplicar los criterios principales del modulo.
Preparación del proyecto integrador
La evaluación del módulo sigue siendo la evaluación existente. Esta lectura añade una preparación con respuestas abiertas y criterios de revisión; no sustituye preguntas, puntajes ni condiciones de aprobación. Trabaja en una copia de tu proyecto y conserva su contrato HTTP.
Caso ficticio: una API de tareas
Una tarea tiene identificador, título, estado y propietario. Propón qué debe ocurrir al consultar una tarea que no existe, crear una tarea con título vacío o leer una tarea de otro usuario. Define primero respuesta y estado HTTP; luego revisa si el handler implementa ese contrato.
| Situación | Qué debes justificar |
|---|---|
| GET de una tarea existente y autorizada | Respuesta JSON y campos públicos |
| ID inexistente | Tratamiento coherente de un recurso ausente |
| JSON inválido o título vacío | Validación y mensaje sin detalles internos |
| Tarea de otro propietario | Autorización por recurso, no solo sesión |
| Fallo del almacenamiento | Respuesta controlada y registro sin datos privados |
Evidencia que preparar
- Escribe una tabla del contrato para las rutas principales.
- Separa la validación de entrada, el caso de uso y el acceso a datos cuando esa separación haga el proyecto más legible.
- Añade una prueba de handler con
httptestpara un caso válido y otro rechazado. - Ejecuta
go test ./...y registra el resultado real, incluida cualquier prueba fallida. - Documenta cómo iniciar el proyecto y qué configuración de ejemplo necesita; no incluyas secretos.
Preguntas abiertas de repaso
- ¿Por qué un usuario autenticado todavía puede carecer de permiso sobre una tarea?
- ¿Qué prueba demuestra que un JSON inválido no llega a guardarse?
- ¿Cómo detectas una diferencia entre el status prometido y el recibido?
- ¿Qué cambia en tu contrato si el borrado debe ser idempotente?
- ¿Qué limitación del proyecto explicarías antes de usarlo fuera de un entorno de práctica?
Criterios para tu autoevaluación
Revisa claridad del contrato, cobertura de los dos casos propuestos, manejo de errores y reproducibilidad. Señala dónde falta evidencia en lugar de marcarlo como aprobado. Guarda tus respuestas junto con el resultado del test. La autoevaluación prepara la evaluación existente y no añade una certificación ni un puntaje automático.
Referencias para comprobar la implementación
Documentación consultada el 2 de octubre de 2026. Comprueba también las versiones y condiciones de tu proyecto.
Sigue con APIs REST en Go: Concurrencia, Despliegue y Monitoreo
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.