http - servlet - EntityTag-Value, Caching, Comparison-cómo hacer en Jersey

restful java

Question

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

Entonces ocurren 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 la entidad identificada enviada. ¿Cómo comparo esto con el recurso? Porque no adjunté el entityTag al recurso.

4. Solo se trata 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

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

1. Hasta el servidor para decidir: tiene que identificar de forma única la versión del recurso en un momento dado (puede ser un número de revisión del recurso, o 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 uno de ellos o ambos.

En el lado del servidor, Jersey proporciona soporte para evaluar ETags y generar una respuesta. Por ejemplo, su método de recursos puede verse así:

@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();
}

El mismo tipo de soporte se proporciona para el encabezado de última modificación y también tanto etag como último modificado.

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