EntityTag - Value, Caching, Comparison - how to in Jersey

Question

al momento sto cercando di abilitare il caching per il mio servizio riposato in jersey.

Quindi ci sono alcune domande.

1. Qual è il valore di entityTag? Può essere solo una stringa casuale generata univoca?

2. Quando faccio una richiesta di posta dal mio client al server, ottengo indietro la risposta con il tag di entità. Domanda: come memorizzarlo nella cache e come faccio a sapere quale entityTag memorizzato nella cache devo inviare per la richiesta successiva?

3. Sul lato server viene visualizzata l'entità entitàTag. Come posso confrontare questo con la risorsa? Perché non ho allegato il tag entity alla risorsa.

4. Si tratta di confrontare i tag di entità. Quindi, quando ho bisogno del valore dell'intestazione dell'ultima modifica?

Siamo spiacenti, sarebbe bello avere un esempio per server e client. Non riesco a trovare nulla per questo problema. Come inviare tag di entità in richiesta, come confrontarli sul lato server e cosa è stato modificato l'ultima volta.

Answer 1

Gli ETag forniscono un meccanismo per la cache client per convalidare se il contenuto della cache è ancora aggiornato. Per quanto riguarda le vostre domande:

1. Fino al server di decidere - deve identificare in modo univoco la versione della risorsa in un determinato punto del tempo (può essere un numero di revisione della risorsa, o CRC32 hash della rappresentazione risorsa o qualsiasi altra cosa che può essere utilizzata per determinare se la risorsa è stata modificata o meno)
2. Jersey non fornisce alcun supporto per il caching sul lato client al momento. È possibile creare la propria cache implementando un ClientFilter che intercetta una richiesta client, esaminando la HashMap interna (ad esempio) che associa URI, tipo di supporto e metodo di richiesta a una risposta memorizzata nella cache. Prende ETag da quella risposta memorizzata nella cache e la allega alla richiesta del client. Quando il server risponde, il filtro verifica se il server ha risposto con il codice di stato 304 (Non modificato), in caso affermativo, il filtro restituisce la risposta precedentemente memorizzata nel client, in caso contrario, memorizza nella cache la risposta restituita dal server e la restituisce al cliente.
3. Inviando il tag dell'entità nella richiesta, il client dice in sostanza: "Ho una versione dell'entità corrispondente al tag dell'entità - l'entità è sempre la stessa o è cambiata? Se è cambiata, mandami il numero nuova versione dell'entità insieme al tag! ". Se il server non ha inviato alcun tag di entità nella risposta iniziale, il client non conosce il tag corrispondente all'entità memorizzata nella cache e quindi non può inviare un tag nella sua richiesta. Il server conosce il significato del tag - per il client il valore del tag è opaco.
4. È possibile scegliere tra uno o entrambi.

Sul lato server, Jersey fornisce supporto per la valutazione degli ETag e la generazione di una risposta. Per esempio. il metodo di risorsa può apparire come segue:

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

stesso tipo di sostegno è previsto per ultima modifica di intestazione e anche sia ETAG e dell'ultima modifica.

questo articolo di Wikipedia fornisce una bella panoramica di ETags: http://en.wikipedia.org/wiki/HTTP_ETag