CAPÍTULO 3 · Cada pieza encuentra su responsabilidad
Acordar cómo entra y cómo sale la información
Ya conocemos las entidades y sus relaciones, pero una petición HTTP trae valores sin interpretar: textos, números, campos ausentes o nombres inesperados. El navegador puede validar algunos, aunque no podemos suponer que todas las solicitudes pasarán por nuestro formulario. También debemos evitar devolver información solo porque existe como columna en el modelo.
Los serializers nos ayudan a establecer ese intercambio. Definimos qué datos acepta una operación, cómo se validan y qué representación recibirá quien la consulte. Así, el modelo no tiene que convertirse automáticamente en el contrato público completo. Cuando hay un error de entrada, podemos responder de una manera que el cliente comprenda.
Con ese acuerdo ya es posible construir vistas que consulten y guarden. Precisamente ahí empieza otra forma de crecimiento: un mismo archivo puede reunir lecturas, cambios y decisiones de negocio. Para que el equipo siga entendiendo lo que hace cada parte, necesitamos distinguir primero la intención de cada operación.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una aduana para los datos
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Entrada. Datos sin confiar
- Serializer. Valida forma y valores
- Datos válidos. Llegan al caso de uso
- Salida. Contrato explícito de respuesta
01 / EL PROBLEMA
¿Para qué sirve?
No todo campo del modelo debe ser editable desde una API. Un serializer define qué se recibe, qué se valida y qué se devuelve.
02 / COMPRENDER
El concepto, explicado
ModelSerializer reutiliza estructura del modelo. Un Serializer normal sirve cuando la entrada no coincide con una tabla, como un rango de fechas o una conversión.
Los campos de lectura pueden incluir información relacionada. Eso hace cómodo el frontend, pero exige pensar en la consulta ORM para evitar N+1.
03 / CONSTRUIR
Implementación paso a paso
- Define fields explícitos.
- Marca identificadores y timestamps como read_only.
- Normaliza strings de entrada.
- Prueba errores por campo.
04 / APLICAR
Ejemplo en SensorHub
# catalogo/serializers.py
from rest_framework import serializers
from .models import Sensor
class SensorSerializer(serializers.ModelSerializer):
station_name = serializers.CharField(source="station.name", read_only=True)
class Meta:
model = Sensor
fields = ["id", "code", "station", "station_name", "active", "created_at"]
read_only_fields = ["id", "created_at"]
def validate_code(self, value):
value = value.strip().upper()
if not value:
raise serializers.ValidationError("El código es obligatorio.")
return valueCómo leer el ejemplo
- source recorre la relación para serializar station_name.
- validate_code devuelve el valor normalizado que después se guardará.
- is_valid(raise_exception=True) convierte errores de entrada en una respuesta DRF de validación.
Error habitual
No uses fields="__all__" sin revisar exposición y permisos de escritura.
05 / PRACTICAR
Tu turno
Prueba el código " temp-01 " y un código vacío.
Ver solución orientativa
El primero se normaliza a TEMP-01; el vacío genera un error code y no crea ningún sensor.
06 / VERIFICAR
Cómo sabes que funciona
- id no es editable desde el payload.
- La API devuelve errores comprensibles para cada campo.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
CQS: consultar y ejecutar →Continuar en modo relato