Preguntas

El error 412 ocurre cuando el servidor rechaza la solicitud porque no se cumplen las condiciones previas que el cliente envió en las cabeceras.

Es decir: el cliente dijo “haz esto solo si se cumple tal condición”, pero el servidor verificó que no se cumple, y por eso rechaza la operación.

Este error es común en APIs REST, sistemas con control de versiones y validaciones de integridad.

 Causas más comunes

•  La cabecera If-Match no coincide (el recurso cambió desde la última vez que el cliente lo vio).

•  La cabecera If-Unmodified-Since falla porque el recurso sí fue modificado.

•  Ediciones simultáneas del mismo recurso generan conflicto.

•  Control de versiones (ETags) no coincide, indicando datos desactualizados.

•  El cliente está enviando información vieja o corrupta.

•  Reglas de negocio que exigen que el recurso esté en un estado específico.

 Soluciones recomendadas

1) Actualizar el recurso antes de modificarlo

El 412 ocurre porque el cliente tiene una versión antigua del recurso.

Solución:
Haz un GET del recurso → obtén la versión actual → vuelve a intentar la operación.

2) Verificar cabeceras condicionales

If-Match

El servidor solo ejecutará la operación si el ETag coincide:

Si cambia, devuelve 412.

If-Unmodified-Since

El servidor solo procede si el recurso NO ha sido modificado desde esa fecha.

Si alguien editó el recurso → 412.

3) Usar control de versiones correcto con ETags

Los ETags sirven para evitar sobrescribir cambios de otros usuarios.

Ejemplo en la respuesta:

Si intentas modificarlo usando otra versión → 412.

4) Resolver conflictos de edición simultánea

En sistemas colaborativos:

• Dos usuarios editan el mismo documento.

• El segundo usuario intenta guardar sin saber que el primero ya modificó.

Solución:
Mostrar mensaje elegante:

“Este recurso fue modificado por otro usuario. Actualiza antes de continuar.”

5) Revisar reglas de negocio

Ejemplos:

• No puedes actualizar un pedido que ya está “cerrado”.

• No puedes eliminar un recurso si sigue siendo referenciado.

Cuando estas condiciones no se cumplen → 412.

6) Corregir integraciones de APIs

APIs como Google, Amazon, Stripe, Microsoft o APIs REST personalizadas usan 412 si:

• El cliente no envía ETag

• Envía ETag incorrecto

• Intenta modificar un recurso fuera de estado permitido

Revisar documentación del endpoint.

 Consejo Pro

Usa condiciones previas para evitar errores de concurrencia:

• En APIs: utiliza If-Match con ETags para actualizaciones.

• En sistemas colaborativos: implementa control de versiones.

• En sitios con alta concurrencia: valida que el recurso no cambió desde que el usuario lo abrió.

Esto evita pérdida de información y sobreescritura accidental.