Operaciones CRUD: Create, Read, Update, Delete explicado

¿Qué es CRUD?

CRUD son las siglas de Create, Read, Update, Delete (crear, leer, actualizar y eliminar), las cuatro operaciones básicas sobre datos almacenados. Una base de datos las ejecuta como sentencias SQL, una API REST las expone como métodos HTTP y la mayoría de los paneles de administración se construyen a su alrededor. Si una función se describe con uno de esos cuatro verbos, es CRUD.

Cómo se corresponde CRUD con SQL y HTTP

Ejemplo de CRUD: una tabla users

Las mismas cuatro operaciones en SQL:

-- Create
INSERT INTO users (email, name) VALUES ('alice@example.com', 'Alice');
-- Read
SELECT * FROM users WHERE id = 42;
-- Update
UPDATE users SET name = 'Alice Smith' WHERE id = 42;
-- Delete
DELETE FROM users WHERE id = 42;

Y como llamadas a una API REST, donde cada llamada llega a un endpoint de API:

POST   /users        {"email": "alice@example.com", "name": "Alice"}   -> 201 Created, Location: /users/42
GET    /users/42                                                      -> 200 OK
GET    /users?limit=20&offset=0                                       -> 200 OK (a page of users)
PUT    /users/42     {"email": "alice@example.com", "name": "Alice Smith"} -> 200 OK (full replace)
PATCH  /users/42     {"name": "Alice Smith"}                          -> 200 OK (partial change)
DELETE /users/42                                                      -> 204 No Content

PUT frente a PATCH

Un PUT reemplaza el recurso completo, así que quien llama envía el estado nuevo entero. Un PATCH son instrucciones para cambiar solo una parte, así que se envían únicamente los campos que cambian. Usa PATCH en los formularios de edición habituales y PUT cuando el cliente tiene realmente el registro completo.

Qué métodos se pueden reintentar sin riesgo

Según MDN, GET, PUT y DELETE son idempotentes: repetir la petición deja el servidor en el mismo estado. En POST y PATCH no está garantizado, así que un Create reintentado puede crear un duplicado. Las claves de idempotencia lo resuelven; consulta idempotencia y la semántica HTTP en la RFC 9110.

CRUD más allá de REST

GraphQL no tiene endpoints por verbo: las lecturas son queries y las escrituras son mutations. gRPC nombra sus métodos según la operación (CreateUser, GetUser). Los sistemas basados en eventos guardan eventos como UserCreated en lugar de sobrescribir filas. Más detalle en la entrada sobre GraphQL.

mutation { createUser(input: {...}) { id } }
query    { user(id: 42) { id name } }
mutation { updateUser(id: 42, input: {...}) { id } }
mutation { deleteUser(id: 42) { success } }

Errores comunes en CRUD

• Listados sin paginación. Un endpoint que devuelve todas las filas se vuelve lento y acaba fallando al crecer la tabla. Consulta la paginación de API.
• Consultas N+1. El listado lanza una consulta extra por cada registro. Usa joins o carga anticipada.
• Actualizaciones perdidas. Dos clientes editan el mismo registro y gana la última escritura. Usa un ETag o un campo de versión.
• PUT con cuerpo parcial. El servidor reemplaza el registro y vacía los campos que quien llama omitió.
• 200 con cuerpo vacío para un registro inexistente. Devuelve 404.
• Borrados en cascada silenciosos. Eliminar un usuario borra también sus pedidos.
• SQL construido con datos del usuario. Usa siempre consultas parametrizadas.
• Autorización solo en las escrituras. Las lecturas también filtran datos.

Cómo probar y monitorizar APIs CRUD

Una API CRUD suele fallar bajo carga en los mismos puntos: listados lentos, bloqueos en las actualizaciones y creaciones duplicadas al reintentar. Escribe un flujo completo de crear, leer, actualizar y eliminar y ejecútalo con las pruebas de carga de LoadFocus, que lanzan scripts de JMeter y k6 desde 25 regiones en la nube. Tras el lanzamiento, la monitorización de APIs puede comprobar tus endpoints de lectura (las comprobaciones gratuitas se ejecutan cada 5 minutos) y validar el código de estado y el cuerpo de la respuesta. Para saber más: cómo hacer pruebas de carga a APIs RESTful y pruebas de API.

Preguntas frecuentes: operaciones CRUD

¿Todas las APIs son CRUD?

Muchas APIs de datos encajan bien en CRUD. Las que ejecutan lógica de negocio suelen usar otros verbos, por ejemplo POST /transfers o POST /users/42/send-welcome-email.

¿Cuál es la diferencia entre CRUD y REST?

CRUD son las cuatro operaciones. REST es un estilo de arquitectura para APIs que a menudo, aunque no siempre, asigna esas operaciones a métodos HTTP.

¿Conviene borrado lógico o físico?

El borrado lógico (una marca de tiempo deleted_at) conserva el historial y se puede deshacer. El borrado físico hace falta cuando hay que eliminar datos por motivos legales o liberar espacio.

¿Cómo evito las actualizaciones perdidas?

Con concurrencia optimista: el cliente envía el ETag o la versión que leyó y el servidor rechaza la escritura si el registro ha cambiado desde entonces.

¿Todo modelo necesita las cuatro operaciones?

No. Los recursos de solo lectura o de solo añadir son válidos. Expón únicamente las operaciones que tu caso de uso necesita.