Restituzione di HTTP 304 non modificato (senza memorizzazione nella cache sul lato server)

Question

Restituzione di HTTP 304 non modificato (senza memorizzazione nella cache sul lato server)

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

5

In HTTP 1.1, un server web può restituire una risposta 304 non modificata quando un'intestazione If-None-Match è inclusa nella richiesta GET.

Per l'API REST, ho visto solo implementazioni che coinvolgono il caching lato server dell'intero contenuto della risposta, in cui la cache viene in genere invalidata in successive richieste di modifica della stessa risorsa (come PUT, PATCH o DELETE).

Come forse saprai, l'invalidazione della cache può essere difficile da fare, in particolare quando si ridimensiona o quando l'origine dati sottostante può essere modificata con altri mezzi. Ciononostante, anche senza il caching completo lato server, sicuramente la sola omissione del contenuto della risposta potrebbe produrre un significativo vantaggio in termini di prestazioni.

Supponiamo che un server Web intercetti ogni risposta a una richiesta GET e aggiunga semplicemente un'intestazione ETag che specifica un valore hash per il contenuto della risposta. Quindi, nelle successive richieste GET, l'intestazione If-None-Match può essere elaborata (di nuovo, dopo il fatto) in modo da avere la risposta sovrascritta con una risposta 304 non modificata. Tale implementazione, senza stato o meno, continuerebbe a elaborare prima ogni richiesta GET nell'origine dati sottostante.

Pertanto, la mia domanda non riguarda la riduzione del costo di colpire l'origine dati sottostante (con la memorizzazione nella cache), ma la riduzione del costo della rete.

È un'idea sciocca?

Potrebbe essere utile abilitare su (quasi) tutte le API?

rest http

posta Biscuits 20.10.2016 - 02:53

fonte

2 risposte

1

Se molti dei tuoi client sono app mobili e in genere si connettono tramite cellulare e hai abbastanza potenza del server, mi sembra ragionevole.

risposta data 20.10.2016 - 04:42

fonte

Leggi altre domande sui tag rest http

Non capendo il concetto di come rendere la mia applicazione GUI Riguardo l'organizzazione delle funzioni di utilità di spostamento bit in C ++

score 2 · Accepted Answer

Non sono sicuro del commento "ogni API". Ci sono molte situazioni in cui può fare più male che bene.

Considera un'API che restituisce cifre azionarie altamente dinamiche. Il tasso di successo sui valori ETag potrebbe essere molto piccolo, mentre il costo aggiuntivo di elaborazione del calcolo dell'hash della risposta verrebbe aggiunto a ciascuna chiamata. Inoltre, se il tuo tasso di successo ETag è vicino a zero, allora spenderai più larghezza di banda sulle intestazioni ETag rispetto al salvataggio nei casi rari in cui il suo valore corrisponde.

Ovviamente, ci sono molte situazioni in cui è utile. Per determinare quando, guarderei i potenziali tassi di successo (cioè quanto spesso otteniamo una corrispondenza su ETag), misurandoli idealmente su un campione in produzione. Quindi collegalo a una formula che confronta il risparmio di rete con l'impatto della CPU. Cellular è in effetti un caso in cui le considerazioni sull'ampiezza di banda / latenza di solito superano la potenza di elaborazione.

Forse potresti condividere i tuoi casi d'uso e le API che hai in mente. Ciò contribuirebbe a dare consigli più specifici.