Immaginiamo di trovarci in uno scenario in cui abbiamo un'applicazione (può trattarsi di un sito web, o un App su device) che consuma servizi esposti tramite Web API. Nel caso in cui la risposta di uno dei servizi invocati sia scarsamente variabile, ma le richieste siano ripetute nel tempo - per esempio il contenuto di un menu - il caching client side è uno dei metodi più efficaci per raggiungere immediatamente due importanti risultati:

• Migliorare le prestazioni generali del sistema, soprattutto in termini di latenza vista dall'utente: in questo modo, infatti, il client mantiene il dato in una cache locale, e la riutilizza nelle chiamate successive, evitando di dover connettersi al servizio;
• migliorare la scalabilità server side, perchè il numero di richieste che il nostro servizio si troverà a dover gestire sarà inferiore.

Al fine di attivare questa funzionalità, è sufficiente impostare l'attributo ResponseCache, a livello di singola action o di controller:

[HttpGet, 
    ResponseCache(Location = ResponseCacheLocation.Any, Duration = 300)]
public IEnumerable<string> Get()
{
    return new string[] { "value1", "value2", "value3" };
}

Nel nostro caso, ad esempio, stiamo specificando che la risposta può essere mantenuta in cache per un TTL di 300 secondi. Si tratta di un caso molto semplice, perchè applicato a un metodo che non accetta parametri. Volendo, possiamo sfruttare anche le proprietà VaryByHeader o VaryByQueryKeys per indicare quali chiavi dell'header o della querystring devono essere considerate come invarianti per la cache.

Il risultato di questo attribute è l'aggiunta di un header cache-control alla risposta, che indica al browser (o al generico client HTTP) che è effettivamente possibile mantenere una cache locale della stessa:

HTTP/1.1 200 OK
Cache-Control: public,max-age=300
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Server: Kestrel
X-Powered-By: ASP.NET
Date: Sun, 11 Mar 2018 16:22:17 GMT

1c
["value1","value2","value3"]
0

L'esempio mostrato ci consente di migliorare facilmente le prestazioni generali del sistema. Un problema, però, è che non possiamo aumentare in maniera indefinita il TTL: quando un elemento è in cache sul client, infatti, è al di fuori del nostro controllo e non possiamo, per esempio, invalidarlo se i dati cambiano. Questo purtroppo è un vincolo dal quale non possiamo sfuggire facilmente, che fa sì che ogni 5 minuti - secondo il codice che abbiamo scritto sopra - ogni client sia comunque costretto a effettuare un nuovo download del contenuto. Nel prossiom script vedremo come mitigare questo problema.