Reto: la capa de datos de una API

Reto40 min60 XP

El corazón de toda API es su lógica CRUD: crear, leer, actualizar y borrar registros de forma confiable. Hoy construyes esa capa de datos completa para Mi Bolsillo con sqlite3 —corriendo en vivo— con validación incluida, tal como viviría dentro de un service de FastAPI. Luego, la solución muestra cómo se envuelve en endpoints FastAPI. Es el núcleo real de un backend: la lógica que persiste y protege los datos.

Reto

Capa de datos CRUD

Media35 min60 XP(×2 sin mirar la solución)

Qué debes construir

Una clase RepositorioGastos que gestione gastos en una base de datos SQLite, con validación:

__init__: conecta a una base en memoria y crea la tabla gastos (id, nombre, valor, categoria).
crear(nombre, valor, categoria): valida (nombre no vacío, valor positivo; lanza ValueError si no) e inserta, devolviendo el gasto creado con su id.
listar(categoria=None): devuelve todos los gastos, o los de una categoría si se indica.
obtener(gasto_id): devuelve un gasto por id, o None si no existe.
actualizar(gasto_id, valor) y borrar(gasto_id): modifican/eliminan un registro.

Reglas

Usa parámetros ? en el SQL (nunca f-strings con datos: inyección SQL).
Valida en crear lanzando ValueError con mensaje claro.
Devuelve diccionarios (no filas crudas) para que sea fácil convertir a JSON.

35:00

Cuando estés listo, arranca el reloj.

Lo que este reto consolida —el núcleo de un backend:

La capa de datos es el corazón. Todo lo demás (rutas, auth) envuelve esta lógica CRUD. Aislarla en un repositorio/service la hace testeable y reutilizable, independiente de FastAPI.
Validar antes de persistir. Los datos malos se rechazan con ValueError ANTES de tocar la base —nunca guardas basura—.
SQL seguro. Parámetros ? siempre: la inyección SQL es de los ataques más comunes y más fáciles de evitar.

Autoevaluación: ¿el CRUD completo funciona (crear, listar, filtrar por categoría, obtener, actualizar, borrar)? ¿la validación rechaza un gasto con nombre vacío o valor negativo? Este RepositorioGastos es la capa de datos REAL de una API —la lógica que persiste y protege—. Envolverla en FastAPI es directo: cada método se vuelve un endpoint. Así se vería:

routers/gastos.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

app = FastAPI()
repo = RepositorioGastos()

class GastoNuevo(BaseModel):
  nombre: str = Field(min_length=1)
  valor: int = Field(gt=0)
  categoria: str = "otros"

@app.get("/gastos")
def listar(categoria: str | None = None):
  return repo.listar(categoria)

@app.get("/gastos/{gasto_id}")
def obtener(gasto_id: int):
  gasto = repo.obtener(gasto_id)
  if gasto is None:
      raise HTTPException(status_code=404, detail="Gasto no encontrado")
  return gasto

@app.post("/gastos", status_code=201)
def crear(gasto: GastoNuevo):
  return repo.crear(gasto.nombre, gasto.valor, gasto.categoria)

@app.delete("/gastos/{gasto_id}", status_code=204)
def borrar(gasto_id: int):
  repo.borrar(gasto_id)

Fíjate cómo cada método del repositorio se vuelve un endpoint, con Pydantic validando la entrada y las excepciones convirtiéndose en códigos HTTP (404, 422). La lógica que probaste en vivo ES el backend; FastAPI solo la expone a la web. Ese es el patrón de una API bien hecha: una capa de datos sólida y testeable, y una capa de rutas fina que la expone.

Qué sigue

Módulo 8 conquistado: dominas la ruta de backend con FastAPI —APIs, validación, bases de datos, auth, estructura y tests—. Puedes construir el servidor de cualquier aplicación. El módulo 9 abre la última ruta y una de las más demandadas: DATOS E IA —NumPy, Pandas, visualización y machine learning—, donde Python es el rey indiscutible. Y lo mejor: NumPy y Pandas corren aquí mismo, en vivo.