Es concebible que otro cliente también modifique otros aspectos del recurso en el ínterin. Entonces, ¿es una buena práctica incluir siempre la representación completa en la respuesta a un PUT, a pesar de la sobrecarga de ancho de banda?En REST, ¿debo devolver la representación en respuesta a un PUT?
El comentario de Jldupont me indicó la dirección correcta. Usaré ETags para determinar si el recurso ha sido modificado, haciendo un PUT condicional usando el encabezado If-match, as described here.
Luego, en caso de conflicto, dejaré que el usuario decida si buscará la última representación del servidor (GET) o sobrescribirá los cambios con los suyos.
Por lo tanto, no es necesario devolver la representación completa en la respuesta al PUT solo para ayudar con la detección y resolución de conflictos.
Me gusta pensar que GET y DELETE son una pareja, solo toman una identificación.
POST y PUT parecen un par también. Toman un objeto serializado y lo hacen persistente. En consecuencia, creo que tanto POST como PUT deberían devolver el objeto resultante como creado.
En algunos casos, puede que esté haciendo cálculos adicionales como parte de la persistencia, y el PUT podría reflejar esos resultados calculados. Técnicamente, esta podría ser una tercera violación de forma normal porque tiene valores derivados. Pero a menudo, el objetivo del servicio web es hacer un cálculo de valor agregado como parte de POST y posiblemente PUT.
Aprecio tu filosofía, pero no estoy de acuerdo (al menos parcialmente). La especificación HTTP no (como lo hace para GET) requiere/prohíbe/limita DELETE a solo una URL.Más importante aún, eres * no * el único que cree que este es el caso (y mucho más importante, los principales proyectos de software como Talend están diseñados en torno a esta suposición). BORRAR solicitudes de entidades individuales no necesitan un cuerpo (como GET) , pero las solicitudes de DELETE para colecciones son increíblemente drásticas sin algunos datos que refinan la solicitud – Anthony
En muchos casos (si no en la mayoría), el servidor agregará algo al recurso incluso si se crea o se actualiza a través de PUT. Los ejemplos son marcas de tiempo, un número de versión o cualquier elemento calculado a partir de otros. Esto es cierto incluso si sigue el enfoque RESTful y no utiliza PUT para actualizaciones parciales.
Por esta razón, la devolución de la representación del recurso actualizado o creado suele ser una buena idea para las solicitudes PUT. Sin embargo, no necesariamente lo llamaría una "mejor práctica": si PONES un archivo de imagen gigante de 2GB, probablemente no quieras devolverlo como parte de la respuesta.
La inclusión de un ETag, por otro lado, definitivamente merece el estado de "mejores prácticas".
Es posible que desee considerar devolver una respuesta 303 See Other con la cabecera Location establecido en la URI del recurso actualizado (Post/Redirect/Get). De esta forma, el cliente recibe el estado actual del recurso (si elige seguir el encabezado Location) incluso si se ha editado entre tanto, y no corre el riesgo de volver a enviar la solicitud si utiliza un navegador.
Sin embargo, este patrón no permite enviar el código de éxito apropiado (200 OK, 202 Accepted, etc.) que puede ser útil para el cliente. Además, dependiendo de su definición de REST, puede considerar que se trata de una práctica no estándar.
Probablemente sea más apropiado si los clientes son navegadores operados por personas.
¿sería mejor devolver un identificador único asociado con la transacción? Ahorra ancho de banda y evita tener que volver al servidor de todos modos para asegurarse de que no ocurra nada en el ínterin. Es decir. si devuelve los datos, de todos modos puede ser obsoleto. – jldupont
Eso es extraño ... Me estaba haciendo esa misma pregunta hace 20 minutos ... – skaffman