Dominio Profesional de FastAPI: Construcción de APIs Escalables y Seguras

Este curso acompaña la construcción de una API de gestión de contenidos desde sus decisiones internas hasta una validación de producción simulada. El escenario común será una biblioteca editorial: personas autenticadas crean artículos, los clasifican con etiquetas, los consultan y los modifican según su rol. La API deberá conservar reglas de negocio verificables, responder de forma consistente y dejar evidencia de sus decisiones técnicas.

En el primer módulo se organiza el proyecto por responsabilidades. Separar routers, esquemas, servicios, configuración y acceso a datos permite localizar cambios sin convertir main.py en un punto de acoplamiento. También se practican dependencias reutilizables y un ciclo de vida explícito para preparar y liberar recursos. La meta no es acumular carpetas, sino justificar qué componente conoce cada regla y cómo se prueba sin levantar toda la aplicación.

El segundo módulo protege el límite de confianza. Se distingue autenticación de autorización, se valida un token y se comprueba el permiso concreto antes de modificar un recurso. Los roles no sustituyen las reglas de propiedad: un editor puede publicar contenido permitido, pero no necesariamente administrar cuentas. CORS, límites de solicitudes y validación de entrada se estudian como controles complementarios, con configuraciones que puedan comprobarse mediante casos aceptados y rechazados.

El tercer módulo conecta la API con persistencia SQL y documental. Se modelan relaciones entre autores, artículos y etiquetas, se observan transacciones y se evitan consultas innecesarias. La comparación con MongoDB se centra en elegir una representación adecuada para documentos variables, no en presentar una base de datos como solución universal. En escenarios con más de un almacén se separan sesiones, se identifica qué puede revertirse y se documentan los límites de consistencia.

El cuarto módulo convierte esas decisiones en evidencia operativa. Los tests unitarios aíslan reglas puras; los de integración comprueban rutas, dependencias y respuestas HTTP. OpenAPI se trata como contrato revisable: nombres, parámetros, códigos y esquemas deben coincidir con el comportamiento. El despliegue se ensaya mediante una imagen reproducible, variables de entorno no sensibles en el código y una comprobación de salud. El flujo de integración continua debe detener una publicación si falla una prueba o si el contrato cambia sin revisión.

El proyecto integrador reúne todo en una API de contenidos. Primero se redactan recursos, estados, permisos y errores; después se implementan endpoints protegidos y operaciones transaccionales; finalmente se añaden pruebas, documentación y una ejecución simulada de despliegue. El trabajo final no se evalúa por cantidad de archivos, sino por trazabilidad: cada requisito debe enlazarse con una ruta, una regla, una prueba y una evidencia de ejecución.

Para comprobar el aprendizaje, conserva una tabla de decisiones con tres columnas: problema, elección y evidencia. Añade ejemplos de éxito, rechazo por autenticación, rechazo por permiso, validación incorrecta, conflicto transaccional y respuesta no encontrada. Ejecuta las pruebas en un entorno local autorizado, inspecciona el esquema OpenAPI generado y verifica que una configuración incompleta falle de forma clara. Si una interfaz o dependencia cambia, describe el concepto y la conducta observada, sin afirmar que una versión concreta fue probada cuando no lo fue.