428

Precondition Required

El servidor necesita que compruebes el estado antes de hacer cambios. ¡Seguridad primero!

⚠️ Error del Cliente

🤔 ¿Qué narices es esto?

El error 428 Precondition Required es como un guardia de seguridad que te dice "espera, necesito ver tu identificación antes de dejarte pasar": el servidor requiere que incluyas headers de precondición en tu solicitud.

Este error se usa para prevenir el "problema de lost updates", donde dos usuarios modifican el mismo recurso al mismo tiempo y uno sobrescribe los cambios del otro sin darse cuenta. El servidor te obliga a verificar el estado actual antes de hacer cambios.

  • Falta header If-Match o If-None-Match
  • Intento de modificar sin verificar ETag
  • Política de servidor que requiere precondiciones
  • Protección contra actualizaciones concurrentes

Dato curioso

El 428 se introdujo para combatir el famoso "lost update problem". Es como pedir que confirmes la versión del documento antes de guardarlo, evitando que borres el trabajo de otra persona por accidente.

Lo verás principalmente en APIs REST modernas que implementan control de concurrencia optimista, especialmente en operaciones de UPDATE, DELETE o PUT.

🔧 Cómo arreglar este lío

🚀 Para usuarios normales

  1. Actualiza la página: Recarga para obtener la versión más reciente del recurso.
  2. Vuelve a intentar la operación: El cliente debería manejar esto automáticamente.
  3. Verifica que no hay conflictos: Asegúrate de que nadie más esté editando lo mismo.
  4. Usa un cliente actualizado: Las aplicaciones modernas manejan ETags automáticamente.

🛠️ Para desarrolladores

  1. Implementa ETags: Genera y verifica ETags para el control de versiones.
  2. Añade headers condicionales: Usa If-Match, If-None-Match según corresponda.
  3. Maneja el flujo completo: GET → ETag → PUT/DELETE con If-Match.
  4. Documenta los requisitos: Explica qué headers de precondición necesitas.
  5. Implementa retry inteligente: Reintenta con los headers correctos automáticamente.

Problemas típicos con 428

  • Falta header If-Match:
    El cliente no envía el ETag en operaciones de modificación.
  • ETag desactualizado:
    El cliente usa un ETag de una versión anterior del recurso.
  • Cliente sin soporte ETags:
    La aplicación cliente no maneja headers condicionales.
  • Configuración de API inconsistente:
    Algunos endpoints requieren precondiciones y otros no.

🚀 Respuesta rápida para emergencias

🔥 Si todos los clientes reportan 428:
1. Verifica que los ETags se generan correctamente.
2. Revisa la documentación de la API.
3. Considera hacer las precondiciones opcionales temporalmente.
⚡ Si solo algunos clientes dan 428:
1. Actualiza los clientes para soportar ETags.
2. Implementa el flujo GET → ETag → PUT/DELETE.
3. Añade manejo de errores específico para 428.
🎯 Truco pro:
Implementa retry automático: GET para obtener ETag y reintenta la operación original.