Esto no es una cuestión de debate al colocar hechos o cuando se lee la especificación HTTP & HTTPbis.
ETag es un medio de almacenamiento en caché y control de concurrencia. ETags débiles es solo un medio de almacenamiento en memoria caché de un hombre pobre.
En términos de almacenamiento en caché (GET) - uri + content-type + etag puede ayudarlo a ahorrar ancho de banda al no responder también con la carga útil, pero solo con el código de estado 304.
En términos de control de concurrencia (POST; PUT; PATCH): es impetuoso calcular la ETag en función de URI + tipo de contenido + carga útil de respuesta de bit. ¿Por qué?
- Si se calcula la ETag en base a un objeto entero, un superconjunto de la carga útil de la respuesta (es decir. Su carga útil da a + b, pero el objeto es en realidad a + b + c), y luego hacer un parche para instancia terminará fallando porque el ETag cambió ... usted actualiza ... obtiene los mismos datos pero un ETag diferente ... vuelve a intentar el PATCH con el nuevo ETag, ahora funciona. FAIL
- Si calcula la ETag basada en un subconjunto de la carga, en realidad está forzando al usuario a no estar en control de las condiciones para la llamada insegura sin ninguna transparencia. Un PATCH tendrá éxito incluso si los datos asociados con ese ETag han cambiado, que obviamente no es la intención de la solicitud HTTP. FALL
peticiones condicionales deben ser tratados con una semántica similares a "Teniendo en cuenta que mi visión del mundo sigue siendo el mismo, a continuación, realizar la solicitud. Fallar de otra manera". Mi visión del mundo está hecha de una respuesta pasada (URI + headers + payload).