REST-API-Caching, sollte ich einen Reverse-Proxy oder Memcache (d) verwenden?

Question

Ich habe eine REST-API, in der ich die JSON-Antwort des Index (GET/foo) und die Leseaktionen (GET/foo/1) zwischenspeichern möchte, um die Leistung deutlich zu erhöhen. Wenn für eine Ressource ein POST oder ein PUT vorhanden ist, müssen die Cache-Einträge für den Index und die Leseergebnisse abgelaufen sein, sodass kein alter Inhalt bereitgestellt wird.

Ist dies ein Szenario, das am besten mit einem Reverse-Proxy wie Squid/Varnish gemacht wird oder würden Sie Memcache (d) wählen?

Answer 1

Mit einem Reverse-Proxy, der auf der HTTP-Ebene sitzt, ist mehr transparent. Das bedeutet, dass man sehen kann, was über den Draht passiert. Die schlechte Sache ist, dass nur wenige von diesen Caching authentifizierte Antworten unterstützen, so dass ihre Effizienz auf 0 fallen kann, wenn Ihre Ressourcen Authentifizierung erfordern. Umgekehrte Proxys verfallen auch normalerweise nicht automatisch der Ressource A(), wenn diese vollständig nicht verwandte Ressource B (/foo/1) modifiziert wird. Das ist das richtige Verhalten, das Sie Ihrer Lösung irgendwie hinzufügen müssten.

Beide Probleme können gelöst werden, wenn Sie Memcached verwenden, da es nicht die Transparenzanforderung hat.

Answer 2

Ich würde für einen Reverse-Proxy wie Lack gehen, weil Sie Ihren Dienst implementieren können (und testen), ohne Cachelogik und Caching als separate Schicht hinzufügen. Sie können Ihren Service upgraden/neustarten, während Lack alte Ergebnisse für die GET-Anfrage bereitstellt (großartig für die Verfügbarkeit), und es ist einfach, Regeln in Lack zu erstellen, um vorhandene Cache-Ergebnisse basierend auf bestimmten GET/POST-Aktionen zu löschen.

Answer 3

Wenn Sie verteilte Speicher memcached verwenden möchten, ist eine gute Lösung. https://github.com/rubyorchard/middleman ist ein Reverse-Proxy, der Memcached für das Caching verwendet.