FastAPI es un framework web de Python para crear API HTTP con un contrato claro entre el cliente y el servidor.
Su valor práctico no está solo en escribir rutas con rapidez.
También conecta las anotaciones de tipo de Python, la validación de solicitudes, la serialización de respuestas, la inyección de dependencias y la documentación OpenAPI en un mismo flujo de trabajo.
Por eso resulta útil para equipos que quieren que una API siga siendo legible cuando crece el número de endpoints.
Dónde encaja FastAPI
FastAPI conviene entenderlo como un framework para diseñar API explícitas.
La documentación oficial lo describe como un framework basado en las anotaciones de tipo estándar de Python, con Starlette para la parte web y Pydantic para la parte de datos.
Esta combinación encaja bien en API JSON, backends internos, endpoints de inferencia de modelos, herramientas administrativas y pasarelas de integración.
No sustituye las decisiones de arquitectura.
Una aplicación pequeña puede volverse difícil de mantener si las rutas, los modelos de datos, la autenticación, la lógica de servicio y la persistencia quedan mezcladas en un mismo archivo.
Decisiones de diseño que conviene tomar primero
Antes de añadir muchos endpoints, conviene decidir cómo se separarán las responsabilidades.
Esa decisión pesa más a largo plazo que el nombre de la primera ruta.
- Diseño de URL: mantener coherentes los nombres de recursos, los métodos HTTP y los códigos de estado.
- Diseño de esquemas: separar modelos de solicitud, modelos de respuesta y objetos internos de dominio.
- Dependencias: inyectar autenticación, sesiones de base de datos, configuración y clientes externos en lugar de crearlos dentro de cada endpoint.
- Límites de prueba: probar las rutas y la lógica de servicio por separado cuando sea posible.
Estos límites ayudan a proteger el contrato público de la API frente a cambios internos de implementación.
Usar tipos y Pydantic como contrato de la API
FastAPI convierte la información de tipos de Python en reglas de validación y documentación de API.
Con modelos de Pydantic, el cuerpo de una solicitud puede declarar campos obligatorios, campos opcionales, objetos anidados y tipos de datos esperados usando código Python normal.
Un error habitual es reutilizar el mismo modelo para todas las situaciones.
La creación, la actualización parcial, el almacenamiento y la respuesta pública suelen necesitar reglas diferentes.
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class ItemCreate(BaseModel):
name: str
price: float
@app.post("/items")
def create_item(item: ItemCreate):
return {"name": item.name, "price": item.price}
Cuando la forma de entrada es explícita, quienes usan la API, la mantienen y escriben pruebas pueden trabajar con los mismos supuestos.
Async ayuda, pero no es un atajo
FastAPI puede usar funciones normales con def y funciones asíncronas con async def.
La documentación oficial de Python explica que asyncio sirve para escribir código concurrente con async y await, y que suele encajar bien en código de red limitado por operaciones de entrada y salida.
Por eso async def es útil para llamadas HTTP externas, drivers asíncronos de base de datos, colas y otras operaciones que pasan tiempo esperando.
No hace que el trabajo pesado de CPU sea más rápido por sí solo.
Procesamiento de imágenes, grandes agregaciones de datos e inferencia de modelos suelen pertenecer a un worker, una cola, otro proceso o un servicio separado.
Hacer visible la lógica común con dependencias
El sistema de inyección de dependencias de FastAPI permite que los endpoints declaren lo que necesitan como parámetros de función.
La documentación oficial destaca la lógica compartida, las conexiones de base de datos y los requisitos de seguridad como usos habituales.
En la práctica, esto ayuda a que cada endpoint se centre en su papel: recibir datos, llamar a la lógica adecuada y devolver una respuesta.
La configuración, las sesiones de base de datos, los datos del usuario autenticado y los clientes externos pueden suministrarse mediante dependencias en lugar de recrearse en cada manejador de ruta.
Lista de comprobación antes de producción
Antes de publicar un servicio con FastAPI, hay que revisar el contrato operativo además del código.
- Los errores de validación deben ser comprensibles para quienes consumen la API.
- Los modelos de respuesta no deben exponer campos internos ni secretos.
- Las políticas de autenticación, autorización, CORS y limitación de tasa deben estar definidas.
- Las llamadas a bases de datos y API externas deben tener tiempos de espera.
- Los registros no deben incluir datos personales, tokens ni secretos de la aplicación.
- La documentación OpenAPI debe exponerse solo donde sea apropiado.
- Las pruebas deben cubrir solicitudes correctas y fallos importantes.
FastAPI puede acelerar el desarrollo, pero la calidad en producción sigue dependiendo de la seguridad, la observabilidad y el diseño de errores.
Resumen
FastAPI es una buena opción cuando un backend en Python necesita un contrato de API claro e iteración rápida.
Su flujo basado en anotaciones de tipo, su integración con Pydantic, su soporte de OpenAPI y su inyección de dependencias pueden reducir la distancia entre implementación y documentación.
Los mejores resultados llegan cuando FastAPI se trata como parte de una arquitectura, no como la arquitectura completa.
Empieza con límites claros para entradas, salidas, dependencias y pruebas, y deja que el framework mantenga visibles esos límites.
Referencias
- Documentación de FastAPI
- Dependencias en FastAPI
- Documentación de Python: asyncio
- Documentación de Pydantic