Construir una API completa implica ir más allá de listar y crear registros. Los endpoints de lectura individual, eliminación y actualización son esenciales para cualquier aplicación que gestione datos. A continuación se explica paso a paso cómo implementar el read y el delete de un customer en FastAPI, incluyendo manejo de errores y buenas prácticas.
¿Cómo obtener el detalle de un customer por ID?
Para leer un registro específico se necesita recibir un identificador en la URL. La función read_customer acepta dos parámetros: el customer_id de tipo entero y la sesión de base de datos que permite ejecutar la consulta [01:00].
La ruta se define con app.get y se incluye el customer_id como variable dinámica en el path:
python
@app.get("/customers/{customer_id}", response_model=Customer)
def read_customer(customer_id: int, session: Session):
customer_db = session.get(Customer, customer_id)
if not customer_db:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="Customer does not exist"
)
return customer_db
El método session.get recibe dos parámetros: el modelo (la clase Customer) y el identificador con el cual se realiza la búsqueda en la base de datos [02:10]. Si el registro no existe, la variable queda como None.
¿Qué es HTTPException y por qué usarla?
Cuando un customer no se encuentra, retornar None provocaría un error inesperado. FastAPI ofrece HTTPException, una excepción que al ser lanzada con raise genera automáticamente una respuesta JSON con el código de estado y un mensaje descriptivo [02:40].
El status code 404 indica que el recurso no fue encontrado. En lugar de escribir el número directamente, se importa el módulo status desde FastAPI y se usa status.HTTP_404_NOT_FOUND. Esto mejora la legibilidad del código para cualquier desarrollador que lo revise [03:20].
¿Cómo se refleja el path parameter en la documentación?
Al abrir la documentación generada por Swagger, el endpoint aparece con el customer_id marcado como argumento requerido dentro del path [04:10]. Esto permite probar directamente desde el navegador: primero se lista para verificar registros existentes, luego se consulta por ID.
¿Cómo crear el endpoint de borrado con delete?
El endpoint de eliminación comparte lógica con el de lectura: primero se obtiene el customer y se valida su existencia. La diferencia está en el método HTTP y la acción posterior [04:40].
python
@app.delete("/customers/{customer_id}")
def delete_customer(customer_id: int, session: Session):
customer_db = session.get(Customer, customer_id)
if not customer_db:
raise HTTPException(
status_code=status.HTTP_404_NOT_FOUND,
detail="Customer does not exist"
)
session.delete(customer_db)
session.commit()
return {"detail": "ok"}
Puntos clave del borrado:
- Se usa
app.delete como decorador, lo que diferencia este endpoint del get aunque el path sea idéntico [05:00].
- El response_model ya no es
Customer, porque el registro dejará de existir. Se retorna un JSON simple con {"detail": "ok"} como confirmación.
session.delete(customer_db) marca el registro para eliminación, pero no lo ejecuta inmediatamente [05:30].session.commit() confirma la acción en la base de datos, funcionando como un "enter" que finaliza la operación [05:50].
¿Qué es el patrón CRUD y qué falta por implementar?
El acrónimo CRUD representa las cuatro operaciones fundamentales sobre datos: Create, Read, Update y Delete. Hasta este punto se han construido tres de las cuatro: la creación de un customer, la lectura (tanto listado como detalle individual) y la eliminación.
El endpoint restante es el de actualización (update). Un detalle importante es que el body de actualización puede tener una estructura diferente al de creación: generalmente no incluye el ID, ya que este viene en el path [06:30].
¿Qué buenas prácticas se aplican en estos endpoints?
- Validar existencia antes de operar sobre un registro evita errores silenciosos.
- Usar constantes de status (
status.HTTP_404_NOT_FOUND) en lugar de números mágicos hace el código autodocumentado.
- Separar los modelos de respuesta (
response_model) garantiza que la API devuelva exactamente la estructura esperada.
- El commit explícito asegura control total sobre cuándo se persisten los cambios.
Ahora que conoces la mecánica para leer y borrar registros, el reto es construir el endpoint de actualización. Considera qué campos deben ser opcionales en el body y comparte tu solución en los comentarios.
