API REST caching, dovrei utilizzare un proxy inverso o memcache (d)?

Question

Ho un API REST dove vorrei mettere in cache la risposta JSON dell'indice (GET / foo) e le azioni di lettura (GET / foo / 1) per aumentare significativamente le prestazioni. Quando c'è una POST o PUT su una risorsa le voci della cache per l'indice e leggere i risultati devono essere scaduto, il contenuto in modo che nessun vecchio è servita.

E 'questo uno scenario che ha fatto meglio con un proxy inverso come Squid / Vernice o scegliereste memcache (d)?

Answer 1

Utilizzare un proxy inverso che si trova sullo strato HTTP è più trasparente . Ciò significa che è possibile vedere cosa sta succedendo sul filo. La cosa brutta è che alcuni di questi il ??supporto caching risposte autenticati , quindi il loro rendimento può scendere a 0 se le risorse richiedono l'autenticazione. reverse proxy, inoltre, non scadono di solito automaticamente risorsa A (/foo) quando questa risorsa completamente estranei B (/foo/1) viene modificato. Questo è il comportamento corretto che dovreste aggiungere alla soluzione in qualche modo.

Entrambi questi problemi possono essere risolti se si utilizza memcached, dal momento che non ha l'obbligo di trasparenza.

Answer 2

vorrei andare per un proxy inverso, come vernice, perché è possibile implementare (e test) il servizio senza coinvolgere la logica di cache, e aggiungere il caching come uno strato separato. È possibile aggiornare / riavviare il servizio, mentre la vernice serve vecchi risultati per richiesta GET (ottimo per la disponibilità), ed è facile da impostare regole in vernice per invalide (spurgo) risultati cache esistente sulla base di specifici GET / azioni POST.

Answer 3

Se si desidera impiegare memoria distribuita memcached è una buona soluzione. https://github.com/cpatni/middleman è un proxy inverso che utilizza memcached per la cache.