Recorrido práctico · Inicial a intermedio
Construye una API que se pueda probar, explicar y continuar
Empieza con una respuesta real. Después decide dónde entran los datos, conviértelos en contratos fiables y devuelve salidas y errores que otra persona pueda integrar sin adivinar.
- Una aplicación FastAPI ejecutable
- Un contrato visible en OpenAPI
- Tests y evidencia de casos válidos y fallidos
Tu recorrido en este navegador
Empieza por una respuesta que puedas observar
En el primer paso pondrás en marcha un GET, comprobarás su JSON y lo localizarás en OpenAPI.
0 de 10 pasos marcados como recorridos. Esto indica avance, no dominio.
Ruta principal
10 ciclos: predice, construye, comprueba y transfiere
Cada paso activa una hipótesis, ofrece práctica focalizada y termina con un caso independiente.
Paso 1 · Unidad 2.1
Pon en marcha tu primera API
Arranca una operación GET, recibe JSON y localízala en /docs.
Antes de leer: Antes de ejecutar, predice método, ruta, status, body y dónde debería aparecer la operación en OpenAPI.
Evidencia: Una petición devuelve 200, el cuerpo esperado y una operación visible en OpenAPI.Checkpoint: Sin reutilizar la reparación anterior, predices tres rutas y justificas qué operación recibe cada petición.Paso 2 · Unidad 2.2
Haz que tu API reciba datos con intención
Distingue path, query, cabeceras y body y anticipa un error 422.
Antes de leer: Clasifica identificador, filtro, correlación y representación antes de mirar una firma FastAPI.
Evidencia: Puedes predecir de dónde sale cada valor antes de enviar la petición.Checkpoint: Construyes y verificas una matriz de campo ausente, null, valor y default sin una secuencia prescrita.Paso 3 · Unidad 2.3
Convierte datos inciertos en contratos fiables
Modela creación, actualización y salida sin confundir ausencia con null.
Antes de leer: Predice qué reglas dependen de un campo, de varios campos o de quién puede enviar cada dato.
Evidencia: Demuestras un caso válido y dos fallos distintos con errores localizables.Checkpoint: Refactorizas un modelo único en contratos públicos distintos y pruebas que cada frontera acepta solo lo previsto.Paso 4 · Unidad 2.4
Devuelve respuestas y errores que ayuden a integrar
Alinea status, body, headers, filtrado de salida y OpenAPI.
Antes de leer: Antes de editar, compara qué prometen status, headers, body, modelo de salida y OpenAPI.
Evidencia: La ejecución y el contrato coinciden y ningún campo interno se filtra.Checkpoint: Revisas un cambio únicamente desde diff, OpenAPI y casos HTTP y priorizas divergencias demostrables.Paso 5 · Unidad 3.1
Divide la aplicación sin romper sus rutas
Separa composición, routers y schemas sin cambiar el contrato que ya consumen clientes y tests.
Antes de leer: Calcula las rutas finales a partir de los prefijos y dibuja la dirección de imports antes de mover una línea.
Evidencia: La misma batería de regresión pasa antes y después y el conjunto de operaciones públicas en OpenAPI no cambia.Checkpoint: En un dominio distinto y sin una secuencia de archivos prescrita, modularizas la aplicación y justificas su grafo de imports.Paso 6 · Unidad 3.2
Comparte recursos y configura cada entorno
Declara requisitos por petición, valida configuración externa y garantiza la liberación de recursos.
Antes de leer: Dibuja el árbol desde la operación hasta cada proveedor y predice cuáles se ejecutan una vez por petición, una vez por proceso o alrededor de la respuesta.
Evidencia: Una traza demuestra orden, caché por petición y cleanup; una sustitución de test cambia el proveedor sin editar la ruta.Checkpoint: En la API modular de cumplimiento, sustituyes repetición y globals por proveedores explícitos y pruebas sus límites sin un árbol prescrito.Paso 7 · Unidad 4.1
Haz persistentes tus datos con una sesión segura
Sustituye el estado efímero por SQLite y conserva la frontera pública con una sesión nueva por petición.
Antes de leer: Antes de editar, clasifica qué debe vivir por proceso, por petición, por operación y más allá del proceso; después predice qué dato se perderá al recrear la app actual.
Evidencia: Un recurso creado conserva su id y puede leerse después de construir otra instancia de la aplicación sobre el mismo archivo SQLite.Checkpoint: En el dominio de facturas, haces persistente una creación sin copiar la estructura guiada y pruebas supervivencia entre dos instancias de aplicación.Paso 8 · Unidad 4.2
Consulta y modifica recursos sin perder intención
Filtra y pagina en SQL, aplica PATCH desde campos presentes y elimina con un contrato explícito.
Antes de leer: Predice dos páginas y los tres estados de un PATCH antes de ejecutar; señala qué resultado cambiaría si faltara ORDER BY o exclude_unset.
Evidencia: Una matriz distingue campo omitido, null y valor; una traza SQL demuestra filtros, orden estable, límite y offset antes de serializar la página.Checkpoint: Sobre una base persistente de facturas, diseñas list, PATCH y DELETE desde criterios visibles sin copiar los ensayos ni añadir capas prescritas.Paso 9 · Unidad 4.3
Protege la integridad cuando varias filas cambian juntas
Delega invariantes a constraints, conserva una frontera transaccional y carga relaciones con un presupuesto SQL explícito.
Antes de leer: Antes de editar, predice el DDL que debe impedir el estado inválido, las filas que sobrevivirán a un fallo tras el primer commit y cuántos SELECT emitirá una colección lazy.
Evidencia: Un conflicto conocido deja la Session utilizable, un fallo compuesto no persiste filas parciales y una traza reduce 1+N a un número acotado de SELECT.Checkpoint: En facturas, diseñas cabecera, líneas, constraint y límite transaccional desde criterios visibles, sin copiar la transferencia guiada ni recibir pistas.Paso 10 · Unidad 4.4
Evoluciona el esquema sin improvisar en producción
Versiona una transición de schema, preserva datos existentes y prepara PostgreSQL con una ejecución coordinada.
Antes de leer: Antes de editar, separa modelo deseado, schema desplegado, datos y revisión actual; marca cada drop, rename, backfill y recuperación que el cambio necesita.
Evidencia: Una base v1 poblada llega a head sin perder significado, el seed converge al repetirlo y current coincide con la revisión esperada.Checkpoint: Sobre asignaciones v1 pobladas, diseñas rename, status, eventos y backfill desde criterios visibles, sin una revisión resuelta ni pistas.
Hito antes de modularizar
Integra el contrato completo del Bloque II
El encargo final reúne creación, consulta, actualización parcial, validación, errores y estado reiniciable en memoria sin añadir todavía persistencia o autenticación. Complétalo antes del paso 5 para que el refactor parta de comportamiento integrado y verificable.
Consulta justo a tiempo
Recupera el modelo mental cuando una decisión lo pida
Estas guías conservan el contenido de fundamentos completo. No son una barrera previa: úsalas cerca del problema que quieras explicar o diagnosticar.
Unidad 1.1
Lee una petición y anticipa su respuesta
Úsala cuando: Necesites interpretar método, URL, cabeceras, cuerpo o código de estado.
Unidad 1.2
Diseña un contrato que otros puedan usar
Úsala cuando: Quieras distinguir API, REST, JSON, OpenAPI y las vistas /docs y /redoc.
Unidad 1.3
Elige cuándo esperar sin bloquear
Úsala cuando: Debas justificar def, async def, I/O o trabajo limitado por CPU.
Ver lo que está planificado · 4 bloques, 9 unidades
Este mapa anticipa el crecimiento del curso; no enlaza páginas vacías ni cuenta como contenido disponible.
Bloque V. Seguridad
Diferenciar autenticación y autorización e integrar hashing, OAuth2, Bearer, JWT, roles y permisos.
- 5.1 Identifica usuarios sin guardar contraseñas recuperables
- 5.2 Protege cada recurso con permisos verificables
Bloque VI. Testing, asincronía aplicada y rendimiento
Verificar contratos y elegir con criterio entre ejecución síncrona, asíncrona y thread pool.
- 6.1 Demuestra que la API cumple su contrato
- 6.2 Evita bloquear la aplicación bajo carga
Bloque VII. Integraciones y trabajo fuera del request
Controlar una frontera externa y decidir cuándo el trabajo permanece en la petición, usa caché o se ejecuta aparte.
- 7.2 Consume servicios externos sin quedar a su merced
- 7.3 Saca el trabajo duradero fuera de la petición
Bloque VIII. Entrega y transferencia
Reconstruir, verificar y entregar la API y demostrar sus capacidades sobre un contrato externo acotado.
- 8.1 Empaqueta y ejecuta la API de forma reproducible
- 8.2 Entrega cambios con pruebas y migraciones controladas
- 8.4 Demuestra conformidad en un contexto nuevo