Optimiza tu API con confianza: las vistas genéricas de Django Rest permiten crear una vista de detalle que obtiene, actualiza y elimina un recurso, reduciendo código y errores. Aquí verás cómo pasar de lógica duplicada a una implementación clara y reutilizable.
¿Por qué usar vistas genéricas para el detalle?
Las vistas genéricas permiten obtener el objeto, modificarlo, borrarlo o mostrarlo como JSON sin escribir lógica repetida. En lugar de manejar manualmente el 404 por ID y repetir consultas, se hereda de una clase que ya incluye estas operaciones.
- Menos código y menos duplicación.
- Manejo automático de error 404 cuando el ID no existe.
- Soporte integrado para métodos como GET, PUT y DELETE.
¿Cómo evitar código duplicado con vistas genéricas?
La clave es reemplazar el uso de ApiView por una clase que combine operaciones. En lugar de importar y usar por separado RetrieveApiView, UpdateApiView y DestroyApiView, se utiliza una sola clase que reúne todo: la combinada de retrieve, update y destroy.
# Vista de detalle simplificada (esqueleto)
class PacienteDetailView(RetrieveUpdateDestroyApiView):
queryset = ... # colección de pacientes.
serializer_class = ... # serializador del paciente.
# Ya no se implementa get_object ni el 404 manual.
El resultado: el código “sigue funcionando perfectamente” y se eliminan bloques redundantes.
¿Qué diferencia hay entre las clases individuales y la combinada?
- RetrieveApiView: obtiene un recurso.
- UpdateApiView: actualiza un recurso.
- DestroyApiView: elimina un recurso.
- Combinada retrieve, update y destroy: incluye las tres funcionalidades en una sola vista. Si solo quieres permitir actualizaciones, importa únicamente la de update; si quieres todo, usa la combinada.
¿Qué variables hay que definir al heredar de la clase combinada?
Basta con “volver a definir estas mismas variables” ya usadas en la vista previa, típicamente las que indican la colección de objetos y el serializador. Con eso, no hace falta el código manual para buscar por ID ni devolver 404.
¿Cómo validar desde el navegador que todo funciona?
La verificación es directa: se accede al detalle de un paciente (por ejemplo, el ID 3) y funciona. Aparecen un botón de Delete y un formulario que permite editar; incluso es posible enviar cambios con raw data.
¿Cómo probar GET, PUT y delete desde el detalle?
- GET por ID: obtener el recurso “tres” y ver su detalle.
- PUT para actualizar: cambiar, por ejemplo, el correo a “Platzi” y recibir 200 con el nuevo valor reflejado.
- DELETE: disponible con el botón del detalle.
¿Qué aportan los mensajes de error al front end?
Si envías un dato inválido (por ejemplo, una “fecha de nacimiento” no válida), al guardar se muestran mensajes de error claros. Esto es muy útil para el front end: explica por qué el request falla y qué campo corregir.
¿Qué mejoras aporta el formulario y el raw data?
- Edición directa en el formulario del detalle.
- Envío de cambios con raw data sin copiar y pegar.
- Flujo más rápido para iterar sobre pruebas y validaciones.
¿Qué sigue: view sets y nuevos endpoints?
El siguiente paso es usar view sets para agrupar vistas sin repetirse, incluso cuando aún queden “dos líneas” duplicadas. Con el endpoint de pacientes ya listo usando vistas basadas en clases (tras el refactor desde vistas basadas en funciones), llega el momento de crear los endpoints de doctores y citas. Todo el código, muy parecido entre sí, estará disponible en el repositorio de recursos.
¿Por qué usar view sets para agrupar vistas?
- Reducen repetición en configuraciones comunes.
- Centralizan operaciones de lista, detalle, actualización y borrado.
- Preparan la base para trabajar con varios endpoints sin reescribir lógica.
¿Te quedaron dudas sobre la migración a vistas genéricas o view sets? Comenta qué parte de tu API quieres simplificar y qué operaciones necesitas incluir.
