EntityTag - Value, Caching, Comparison - cómo en Jersey

Question

en este momento estoy tratando de habilitar el almacenamiento en caché de mi jersey de servicio de descanso.

Entonces, surgen algunas preguntas.

1. ¿Cuál es el valor de la entityTag? ¿Puede ser solo una cadena aleatoria generada única?

2. Cuando realizo una solicitud posterior de mi cliente al servidor, recibo la respuesta con la etiqueta de entidad. Pregunta: ¿cómo guardar esto en caché y cómo sé qué entityTag almacenado en caché debo enviar para la próxima solicitud de obtención?

3. En el lado del servidor obtengo el entityTag enviado. ¿Cómo comparo esto con el recurso? Porque no adjunté el entityTag al recurso.

4. Se trata simplemente de comparar entityTags. Entonces, ¿cuándo necesito el último valor del encabezado modificado?

Lo siento, sería bueno obtener un ejemplo para el servidor y el lado del cliente. No puedo encontrar nada para este problema. Cómo enviar entityTags en solicitud, cómo compararlos en el lado del servidor y qué información fue modificada por última vez.

Answer 1

ETags proporcionan un mecanismo para que la memoria caché del cliente valide si el contenido almacenado en caché aún está actualizado. En cuanto a sus preguntas:

1. Hasta el servidor para decidir - que tiene que identificar de forma exclusiva la versión del recurso en un punto dado del tiempo (puede ser un número de revisión del recurso, o de hash CRC32 de la representación de recursos , o cualquier otra cosa que se pueda usar para determinar si el recurso ha cambiado o no)
2. Jersey no proporciona ningún soporte para el almacenamiento en caché del lado del cliente en este momento. Puede crear su propio caché implementando un ClientFilter que intercepta una solicitud del cliente, examina su HashMap interno (por ejemplo) que asigna el URI, el tipo de medio y el método de solicitud a una respuesta en caché. Toma el ETag de esa respuesta en caché y lo adjunta a la solicitud del cliente. Cuando el servidor responde, el filtro comprueba si el servidor respondió con el código de estado 304 (No modificado); si es así, el filtro devuelve la respuesta previamente almacenada en caché al cliente; si no, almacena en caché la respuesta devuelta por el servidor y la devuelve al cliente.
3. Al enviar la etiqueta de entidad en la solicitud, el cliente básicamente dice: "Tengo una versión de la entidad que corresponde a esta etiqueta de entidad - ¿la entidad sigue siendo la misma, o ha cambiado? Si ha cambiado, envíeme la nueva versión de la entidad junto con la etiqueta! ". Si el servidor no envió ninguna etiqueta de entidad en la respuesta inicial, el cliente no conoce la etiqueta correspondiente a la entidad en caché y, por lo tanto, no puede enviar una etiqueta en su solicitud. El servidor conoce el significado de la etiqueta: para el cliente, el valor de la etiqueta es opaco.
4. Puede cualquiera de ellos o ambos.

En el lado del servidor, Jersey proporciona soporte para evaluar ETags y generar una respuesta. P.ej. su método de recurso puede tener este aspecto: se proporciona

@GET 
public Response doGet() { 
    EntityTag et = yourMethodForCalculatingEntityTagForThisResource(); 

    // the following method call will result in Jersey checking the headers of the 
    // incoming request, comparing them with the entity tag generated for 
    // the current version of the resource generates "304 Not Modified" response 
    // if the same. Otherwise returns null. 
    ResponseBuilder rb = request.evaluatePreconditions(new EntityTag("1")); 
    if (rb != null) { 
     // Jersey generated 304 response - return it 
     return rb.build(); 
    } 
    // return the current version of the resource with the corresponding tag 
    return Response.ok(getCurrentVersion(), "text/plain").tag(et).build(); 
} 

mismo tipo de apoyo a la última modificación de cabecera y también los dos etag y último modificado.

Este artículo de Wikipedia ofrece una buena visión general de ETags: http://en.wikipedia.org/wiki/HTTP_ETag