409 Conflict

Uso

Cuando llega un error 409 Conflict, la solicitud es válida pero no puede completarse por una discrepancia de estado. Por ejemplo, el cliente responde a una publicación que ya se ha eliminado, y el recurso de destino ya no se encuentra en un estado compatible. El servidor devuelve este estado para señalar el conflicto.

Nota

409 Conflict significa que la solicitud está bien formada, pero entra en conflicto con el estado actual del recurso (actualización concurrente, creación duplicada). 422 Unprocessable Content significa que el cuerpo de la solicitud es sintácticamente válido, pero semánticamente inválido (no supera las reglas de validación). 400 Bad Request significa que la solicitud en sí está malformada (cuerpo que no se puede analizar, cabeceras inválidas). El 409 tiene que ver con conflictos de estado, el 422 con la validación y el 400 con la sintaxis.

Se espera que el cliente examine el cuerpo del mensaje para determinar cómo resolver el problema. En el caso de responder a una publicación eliminada, el cliente puede optar por abandonar la solicitud, restaurar el hilo anterior o crear un hilo nuevo citando el texto original. Esta acción es responsabilidad exclusiva del cliente, conforme a los requisitos o políticas que establezca el servidor.

Impacto en SEO

Los motores de búsqueda como Google no indexan una URL que devuelve el estado 409. Las URL indexadas previamente que pasan a devolver este código de estado se eliminan de los resultados de búsqueda.

Ejemplo

El cliente intenta etiquetar con un “like” una entrada de blog existente con “ID = 111”. El servidor responde para indicar que la entrada se ha congelado y ya no acepta respuestas ni etiquetas.

Solicitud

POST /blog/update?postid=111&flag=like HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 409 Conflict
Content-Type: text/html
Content-Length: 288

<html>
  <head>
    <title>Blog Entry Frozen</title>
  </head>
  <body>
    <p>This post has been marked read-only. To post
    a reply or tag, change the status and try
    again.</p>
  </body>
</html>

Cómo solucionarlo

Un 409 Conflict significa que la solicitud entra en conflicto con el estado actual del recurso en el servidor.

Obtenga el estado actual del recurso antes de reintentar. Envíe una solicitud GET para recuperar la última versión. El estado del recurso ha cambiado desde que el cliente leyó los datos por última vez. Compare el ETag o el campo de versión devueltos con el valor que conserva el cliente.

Use cabeceras condicionales para detectar conflictos. Incluya If-Match con el valor actual del ETag en las solicitudes PUT y PATCH. El servidor rechaza la solicitud cuando el ETag ya no coincide, lo que evita sobrescrituras a ciegas. Este patrón se denomina control de concurrencia optimista.

PUT /api/resource/42 HTTP/1.1
If-Match: "abc123"
Content-Type: application/json

{"name": "updated value"}

El servidor responde con 409 cuando otro cliente modificó el recurso entre el GET y el PUT.

Fusione los cambios o implemente una lógica de resolución de conflictos. Compare los cambios previstos por el cliente con el estado actual del servidor. Aplique una estrategia de fusión: gana la última escritura, fusión a nivel de campo o solicitar al usuario final que resuelva las diferencias. Las API con un campo version o revision en la carga útil exigen que el cliente incluya el número de versión actual en la solicitud de actualización.

Resuelva los conflictos por recursos duplicados. Al crear un recurso con POST o PUT, el servidor devuelve 409 si ya existe un recurso con el mismo identificador único. Compruebe si hay entradas existentes antes de crear y use una clave de idempotencia para evitar creaciones duplicadas en los reintentos.

Trate los conflictos a nivel de base de datos. Los servidores de aplicaciones respaldados por una base de datos devuelven 409 cuando una restricción de unicidad, una restricción de clave externa o un bloqueo a nivel de fila impiden la operación. El cuerpo de la respuesta suele incluir el nombre concreto de la restricción. Resuelva el conflicto de datos subyacente (clave duplicada, registro padre ausente, transacción concurrente) antes de reintentar.

En los sistemas de control de versiones, descargue la última versión y vuelva a aplicar los cambios. Recupere la revisión más reciente, concilie las diferencias y reenvíe la actualización. Las API basadas en Git (GitHub, GitLab) devuelven 409 cuando un push entra en conflicto con cambios del upstream.

Inspeccione el cuerpo de la respuesta en busca de detalles del conflicto. El servidor suele incluir información que explica la discrepancia: el campo en conflicto, el valor actual o la versión esperada. Use esos datos para determinar la vía de resolución correcta.

Implemente una lógica de reintento con actualización de estado. Para los clientes automatizados, construya un bucle de reintento: obtener el estado más reciente del recurso, volver a aplicar la modificación prevista y reenviarla. Añada retroceso exponencial para no saturar el servidor en condiciones de alta concurrencia.

Referencias de código

.NET

HttpStatusCode.Conflict

Rust

http::StatusCode::CONFLICT

Rails

:conflict

Go

http.StatusConflict

Symfony

Response::HTTP_CONFLICT

Python3.5+

http.HTTPStatus.CONFLICT

Java

java.net.HttpURLConnection.HTTP_CONFLICT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_CONFLICT

Angular

@angular/common/http/HttpStatusCode.Conflict