Meccanismo di memorizzazione nella cache per le API REST

Per un servizio REST, in genere si desidera utilizzare i meccanismi di memorizzazione nella cache disponibili del Web e del protocollo HTTP. Ciò significa utilizzare le direttive di memorizzazione nella cache o tags di identità nelle risposte.

In questo contesto, ciò che si vuole fare è eliminare completamente alcune richieste a determinate risorse o limitare il lavoro che il server deve eseguire una volta ricevuta una richiesta.

Devi analizzare la tua domanda e:

• decidere per quanto tempo le risorse sono sicure per la cache sul lato client. Se qualcosa può tranquillamente essere memorizzato nella cache per un paio di giorni, allora lo dici nella risposta. Se un client utilizza nuovamente la stessa risorsa, non invierà una richiesta al server poiché ha già memorizzato nella cache.
• Se alcune risorse non possono essere memorizzate nella cache sul lato client, è possibile memorizzare la cache sul server. È qui che entrano gli ETags. Il cliente chiede: "Ehi server, ho questa versione. È ancora buono?". Il server dice che va bene o ti dà gli ultimi dati. I nuovi dati ora hanno un altro ETag e puoi ripetere il processo.

Dovresti eseguire una ricerca online per qualcosa come "Strategie di memorizzazione nella cache dell'API REST" e vedere se qualcos'altro potrebbe essere più adatto al tuo caso.

Ora, naturalmente, il caching non avviene da solo. Devi implementarlo. Ciò significa:

• sul lato server è necessario aggiungere direttive di caching e tag di entità e implementare questo meccanismo insieme a una cache effettiva che si trova di fronte al DB (i framework di solito hanno il supporto per cose del genere fino ad un certo punto - quindi potrebbero prendi parte della strada lì).
• Devi assicurarti che la memorizzazione nella cache non interferisca con la coerenza dei dati del tuo servizio;
• i clienti devono giocare bene. Se metti tutto il caching in atto e i clienti decidono di ignorarlo completamente, hai praticamente lavorato per niente. Questo è solitamente risolto "costringendo" il client a giocare bene e rifiutando qualsiasi richiesta che non includa le intestazioni necessarie per ottenere un "hit cache". Questo potrebbe essere più difficile da fare se hai già clienti che non fanno il caching e devi assicurarti che non frenino.

Tipicamente, questo sarebbe gestito in un livello tra il Controller e il DB (comunemente, un livello che implementa il modello di Repository). All'interno di quel livello di repository, avresti il codice che gestisce le operazioni di memorizzazione nella cache.

Un'implementazione ingenua potrebbe semplicemente mantenere un elenco di richieste precedenti e quale fosse la risposta; se una nuova richiesta corrisponde a qualcosa che è stato richiesto in precedenza, si passa la stessa risposta (senza colpire il DB per ottenerlo).

Quindi, inizieresti a migliorare tale implementazione, magari rintracciando quando una risposta memorizzata nella cache è stata ottenuta l'ultima volta dal DB e decidendo di recuperarla nuovamente se l'ultima volta è più vecchia di una certa lunghezza tempo.

Potresti anche scindere altre strategie di invalidazione della cache e usarne diverse per entità diverse (alcune entità potrebbero non essere mai salvate nella cache, altre potrebbero essere cache-based in base al numero di volte in cui sono state richieste piuttosto che al tempo, e comunque potrebbe essere necessario che la cache venga invalidata in qualsiasi momento in cui si verifica un evento di scrittura per un'entità che corrisponde a tale ID ... o eventualmente qualsiasi evento di scrittura per un'entità di quel tipo).

La cosa fondamentale qui è che vuoi dividere la logica dal controller e idealmente tenerla separata dal codice che interroga effettivamente il database.