HTTP Response 412: ¿puede incluir contenido?

Question

Estoy construyendo un almacén de datos RESTful y aprovechando Condicional GET y PUT. Durante un PUT condicional, el cliente puede incluir el Etag de un GET anterior en el recurso y, si la representación actual no coincide, el servidor devolverá el código de estado HTTP de 412 (precondición fallida). Tenga en cuenta que este es un servidor/protocolo basado en Atom.

Mi pregunta es, cuando devuelvo el estado 412 ¿puedo incluir también la nueva representación del recurso o debo el usuario emitir un nuevo GET? La especificación HTTP no parece decir sí o no y tampoco lo hace la especificación Atom (aunque su ejemplo muestra un cuerpo de entidad vacío en la respuesta). Parece bastante inútil no devolver la nueva representación y hacer que el cliente lo OBTENGA específicamente. ¿Pensamientos?

Answer 1

Aunque los GET y PUT condicional se resumen como 'solicitudes condicionales', son muy diferentes conceptualmente. Los GET condicional son una optimización del rendimiento y los PUT condicionales son un mecanismo de control de concurrencia. Es difícil discutirlos juntos.

A su pregunta sobre el GET condicional: si envía GET e incluye un encabezado If-None-Match, el servidor enviará 200 Ok si el recurso ha cambiado y 304 Not Modified si no (si la condición falló) . 412 solo debe usarse con PUT condicionales.

ACTUALIZACIÓN: Parece que he leído un poco la pregunta. A su punto con respecto a la 'actualización' de la copia local sobre un PUT condicional fallido: bien podría ser que un caché ya tenga la versión más nueva y que su refresh-GET se sirva desde algún caché. Hacer que el servidor devuelva la entidad actual con el 412 podría en realidad darle un peor rendimiento.

Answer 2

No, técnicamente no deberías. Los códigos de error generalmente especifican que algo salió mal. Aunque nada le impediría devolver contenido (y de hecho, algunos errores como un 404 devuelven una página bonita que dice que no encontró lo que está buscando), el punto de la respuesta no es devolver otro contenido, sino para devolver algo que te dice lo que estaba mal. Técnicamente, tampoco debería devolver esos datos porque pasó el If-None-Match: etag (supongo que eso es lo que pasó)

En otra nota, ¿realmente necesita optimizar una llamada http adicional?

Cuanto más pienso en esto, más convencido estoy de que es una mala idea - ¿Vas a devolver el contenido sobre cualquier otro error? La semántica de PUT es PUT. La semántica GET se debe usar para GET.

Answer 3

Si el número de solicitudes adicionales incurridas, debido a una solicitud adicional después de un conflicto de actualización, es lo suficientemente importante como para que tenga problemas de rendimiento, le sugiero que podría tener problemas con la granularidad de sus recursos.

¿Realmente espera que millones de veces al día varios usuarios editen el mismo recurso simultáneamente? Quizás necesite almacenar cambios delta en el recurso en lugar de actualizar el recurso directamente. Si realmente existe una gran contención por estos recursos, entonces los usuarios no estarán trabajando constantemente en datos desactualizados.

Si su problema es que su recurso contiene la fecha de la última modificación y el último usuario modificado y debe hacer un GET después de cada PUT, entonces estaría más convencido de la necesidad de cambiar las reglas.

Sin embargo, creo que el rendimiento de la solicitud adicional vale la pena por la claridad para el desarrollador del cliente.