para - http/1.1 200 ok
¿Qué código de estado HTTP usar para rechazar un PUT debido a una falla de bloqueo optimista? (1)
Supongamos que me gustaría implementar algún tipo de bloqueo optimista y usar ETags para indicar el estado de recursos más actualizado. Esto significa que los clientes usarán un encabezado If-Match al PUT para una actualización.
De acuerdo con la especificación HTTP , el servidor debe devolver 412 Precondition failed si la ETag proporcionada para el encabezado If-Match no coincide con el estado actual del recurso.
Sin embargo, 409 Conflict parece estar más cerca de lo que quiero expresar semánticamente, especialmente porque da pautas que incluir en la respuesta.
¿Es terriblemente erróneo devolver 409 en caso de que no coincida con una ETag proporcionada en un encabezado de If-Match ?
De su enlace a la especificación:
Si ninguna de las etiquetas de entidad concuerda, o si se da "*" y no existe ninguna entidad actual, el servidor NO DEBE realizar el método solicitado, y DEBE devolver una respuesta 412 (falla previa a la condición). Este comportamiento es más útil cuando el cliente desea evitar que un método de actualización, como PUT, modifique un recurso que ha cambiado desde que el cliente lo recuperó por última vez.
Debido a que la especificación requiere un HTTP 412 (de hecho, usa "MUST"), y porque está claro que representaron precisamente el caso de uso en discusión, un HTTP 412 parece ser el código de respuesta adecuado.
412 es bastante razonable de todos modos. La solicitud dice que hacer la actualización condicionalmente. El 412 dice que la condición falló, por lo que el servicio no lo hará. Especialmente porque 412 es una buena combinación para el concepto de solicitudes condicionales; 409 parecería adjuntar a un tipo específico de rechazo, que puede ser o no de naturaleza condicional. Por ejemplo, podría ver un servicio que devuelve un 409 en respuesta a una solicitud incondicional para PUBLICAR algo con un conflicto interno.
Pero mira lo siguiente, también desde la especificación:
10.4.10 409 Conflicto
La solicitud no pudo completarse debido a un conflicto con el estado actual del recurso. Este código solo se permite en situaciones en las que se espera que el usuario pueda resolver el conflicto y volver a enviar la solicitud. El cuerpo de respuesta DEBERÍA incluir suficiente información para que el usuario reconozca la fuente del conflicto. Idealmente, la entidad de respuesta incluiría suficiente información para que el usuario o el agente de usuario corrijan el problema; sin embargo, eso podría no ser posible y no es obligatorio.
Es más probable que se produzcan conflictos en respuesta a una solicitud PUT. Por ejemplo, si se estaba utilizando el control de versiones y la entidad que está siendo PUT incluye cambios en un recurso que entran en conflicto con los realizados por una solicitud anterior (de terceros), el servidor podría usar la respuesta 409 para indicar que no puede completar la solicitud . En este caso, la entidad de respuesta probablemente contendría una lista de las diferencias entre las dos versiones en un formato definido por la respuesta Content-Type.
De todos modos, la especificación parece requerir un 412 en contextos de solicitud condicional, mientras que sugiere que los conflictos de versión son un factor clave para 409s. Es posible que el 409 se use cuando el conflicto de versión ocurre como parte de una solicitud incondicional.