Marc Semper Lloret
← Servidor web y API con Node

Sesión 6 · Semana 2

Modificar y borrar

Hoy · Hoja de ruta

  1. 1. Aprende: La diferencia entre reemplazar y modificar, y cómo se borra bien.
  2. 2. Haz: Completa el CRUD de tu recurso.
  3. 3. Comprueba: Repetir una operación no produce efectos distintos.

Antes de empezar · 5 minutos, sin apuntes

  1. Si envías solo el precio, ¿qué debería pasar con los demás campos?
  2. ¿Qué responde un borrado de algo que ya no existe?
  3. ¿Qué pasa si dos personas modifican el mismo producto a la vez?

PUT y PATCH

Método Significa Cuerpo
PUT Reemplaza el recurso entero Todos los campos
PATCH Modifica los campos enviados Solo los que cambian 
// PUT: lo que no llega, se pierde
const reemplazo = validarProductoNuevo(peticion.body);
const actualizado = await servicio.reemplazar(id, reemplazo);

// PATCH: se combina con lo que había
const cambios = validarCambios(peticion.body);      // ninguno obligatorio
const actualizado = await servicio.modificar(id, cambios);

El error clásico es implementar PUT combinando los campos: entonces tienes dos rutas que hacen lo mismo y un contrato que miente. Si solo vas a ofrecer una, ofrece PATCH y dilo en el contrato.

Borrar

const borrado = await servicio.borrar(id);
if (!borrado) throw new ErrorNoEncontrado("Producto no encontrado");
respuesta.status(204).end();

Un 204 no lleva cuerpo: la operación ha ido bien y no hay nada que devolver. Sobre el segundo borrado existen dos posturas defendibles —404 porque ya no está, o 204 porque el resultado deseado se cumple— pero elige una y escríbela en el contrato.

Modificaciones que se pisan

Leer, modificar y guardar no es una operación indivisible

Dos peticiones que llegan casi a la vez leen la misma versión del fichero, cada una aplica su cambio y la segunda escribe encima: el cambio de la primera desaparece sin que nadie se entere.

Con un fichero y poco tráfico es improbable, pero conviene saber nombrarlo. Se resuelve con una versión en el recurso, que el cliente devuelve al modificar: si no coincide, el servidor responde 409 en lugar de pisar. Es el mismo problema que en el módulo de servidor se resuelve con transacciones.

Tarea 6 · El CRUD cerrado

  1. Implementa PATCH con validación de los campos enviados.
  2. Decide si ofreces PUT; si lo haces, que reemplace de verdad.
  3. Implementa DELETE con 204 y su comportamiento documentado.
  4. Comprueba que repetir PATCH y DELETE no produce efectos distintos.
  5. Actualiza peticiones.http con todos los casos nuevos.
  6. Añade una fecha de modificación que el servidor mantiene.
Objetivo mínimoCRUD completo con los códigos del contrato.
Si lo tienesImpide modificar campos que el cliente no debería tocar.
RetoImplementa la versión del recurso y devuelve 409 cuando no coincida.

Cierre de la semana 2

  • Las cinco operaciones funcionan según tu contrato.
  • Toda entrada se valida antes de tocar los datos.
  • Cada operación devuelve el código y el cuerpo acordados.
  • Tu fichero de peticiones cubre también los casos que fallan.
Ver respuestas

1 · Con PUT se pierden; con PATCH se conservan.

2 · Un 204 sin cuerpo, si se borró.

3 · Que la segunda escritura pise a la primera sin que nadie lo note.

Microprueba semanal 2 · 5–10 minutos

Individual, sin IA y sin apuntes.

  1. /api/productos?max=abc y /api/productos?categoria=inexistente: qué código devuelve cada uno y por qué.
  2. Explica qué es una lista blanca de campos y qué evita.
  3. Diferencia entre PUT y PATCH, con un ejemplo de tu proyecto.
---