Utilizzo di '304 Not Modified' e 'If-Modified-Since' su un'API REST come strategia cache

Question

Utilizzo di '304 Not Modified' e 'If-Modified-Since' su un'API REST come strategia cache

#1 da (4 voti)
#2 da (2 voti)

5

Ho il seguente scenario: un'app client che consuma un'API REST. Il client è un'applicazione mobile. Pertanto, memorizza nella cache i dati API per il salvataggio della larghezza di banda e il supporto offline.

Con REST può essere fatto usando l'intestazione If-Modified-Since . È, il sistema di gestione della cache dal lato client memorizza il HTTP-Date e lo invia come intestazione all'interno della richiesta all'API, in cui, viene effettuato un controllo e si verifica di inviare uno stato '304 non modificato' nel caso in cui il la risorsa non è stata modificata dai dati specificati.

The "If-Modified-Since" header field makes a GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field-value. Transfer of the selected representation's data is avoided if that data has not changed (rfc7232#section-3.3 If-Modified-Since).

Supponendo che, per "risorse", potrebbe essere una raccolta o un singolo record, la data di modifica sarebbe la data di modifica della risorsa (cioè, se si tratta di una raccolta di record, la data sarebbe l'intera data di modifica della raccolta ). Quindi, internamente farebbe una query di database per verificare se il record o la raccolta sono stati modificati da allora e produrre una risposta adeguata.

Finora, questo è il modo in cui intendo implementare la strategia di memorizzazione nella cache, il più possibile di REST.

Il problema è che è una decisione progettuale di alto impatto e non sono sicuro che sia un buon approccio o se ci sia un modo migliore di implementarlo. Tutta l'idea si basa sulla logica e su una piccola conoscenza REST e non sono riuscito a trovare alcuna risorsa su come implementarla.

Mi piacerebbe avere qualche critica su questo modello, se sia abbastanza buono, avere un approccio migliore o anche qualche avvertimento per migliorare l'idea attuale, sarebbe tutto apprezzato.

rest caching

posta lenilsondc 12.07.2017 - 19:03

fonte

2 risposte

2

Lo svantaggio del tuo approccio è che non copre molti degli scenari di caching. Ogni elemento sembra essere memorizzato nella cache per sempre (almeno per un tempo molto lungo) e quando il client esaurisce la memoria, decide quali elementi della cache da rimuovere, senza fornire alcun controllo sul processo. Nella vita reale, spesso è necessario essere in grado di avere questo tipo di controllo, per esempio, per esempio, per estrarre dalla cache gli elementi che vengono usati raramente, mantenendo quelli utilizzati più spesso.

Se non hai bisogno di questo tipo di controllo, il tuo approccio è perfetto.

Si noti che se per alcune risorse non si ha l'ultima data di modifica, è possibile utilizzare invece gli ETag HTTP, ad esempio calcolando l'hash dell'oggetto nel database e confrontandolo con l'hash fornito dal client .

risposta data 12.07.2017 - 21:07

fonte

Leggi altre domande sui tag rest caching

Specifiche dei requisiti del software e schemi Postfix vs Prefisso

score 4 · Accepted Answer

If-Modified-Since funziona bene per le singole risorse in cui è facile e veloce determinare se la risorsa è stata modificata. Ad esempio, i server HTTP hanno questa funzionalità integrata per i file statici poiché può utilizzare la data / ora del file. Il concetto generale è che l'elaborazione della risorsa è più costosa rispetto alla determinazione della data di modifica. Lo considererei per le singole risorse, ma non per le raccolte.

Esistono diversi schemi di memorizzazione nella cache tra cui scegliere e dovresti utilizzare solo quello più appropriato per risolvere il problema. In alcuni casi, il caching è dannoso. Esempi:

I risultati sono destinati a modificare ogni richiesta (ad es. alto tasso di variazione)
I proxy possono interrompere gli schemi di memorizzazione nella cache che sono specifici dell'utente (ad esempio uno scenario di posta in arrivo)
Il costo per determinare se l'elemento è più recente è come recuperarlo (ad esempio, la differenza nel tempo per controllare semplicemente una data e ottenere un intero record da un database è solitamente trascurabile, ma fare 2 query quando lo si farà effettivamente peggiora le cose)

Sono stato morso da un numero di bug di caching indotto da proxy, in particolare server proxy vecchi e non ben mantenuti nelle reti dei clienti. Prova con più utenti per assicurarti che gli sforzi di memorizzazione nella cache non peggiorino le cose.