Ich habe eine Anwendung, die Daten von Service2 benötigt, die für immer die gleiche Antwort für eine bestimmte Anfrage zurückgeben, wenn ihre Backing-Datenbank nicht aktualisiert wird. Die Datenbank wird sehr selten aktualisiert, sagen wir zweimal pro Jahr.
Ich möchte eine Lösung entwerfen, so dass die Anwendung die Antworten von Service2 zwischenspeichert, aber extern ein Feature bereitstellt, um den Cache der Anwendung ungültig zu machen. Ich dachte daran, einen REST-fähigen Webservice aus der Anwendung heraus zu sehen, aber ich bin verwirrt, wie man ihn richtig gestaltet.
/application/cache/invalidate ist eine nicht-REST-konforme URL - ich habe über /application/cache/ nachgedacht, die mit HTTP POST aufgerufen werden soll. Es sieht jedoch so aus, dass für einen ordnungsgemäßen RESTful Entwurf, wenn POST zum Aktualisieren einer Ressource verwendet wird, der zu aktualisierende Inhalt im Hauptteil der Anfrage enthalten sein sollte.
Was ist der richtige Weg, um einen "InvalidateCache" -ruhigen Webservice zu entwerfen?
Verwenden Sie DELETE anstelle von POST und für die URL:
In REST werden sowohl PUT als auch DELETE als unabhängige Aktionen betrachtet. Das heißt, sie können mehrmals mit demselben resultierenden Ressourcenstatus wiederholt werden. In diesem Fall ist Ihr Cache die Ressource und mehrere DELETE führen zum selben Status, einem gelöschten Cache.
Sie könnten in Erwägung ziehen, einen Deskriptor zu Ihrer URL hinzuzufügen, um zu verdeutlichen, dass Sie den Inhalt Ihres Cache löschen und nicht das Cache-Objekt selbst löschen. Etwas wie
%Vor%vielleicht, aber das liegt an dir. Wenn Sie diese Route verwenden, können Sie gegebenenfalls auch selektiv aus Ihrem Cache löschen.
Dies beantwortet möglicherweise Ihre Frage nicht direkt, aber Sie können auch in HTTP ETags nachsehen, die sich gut eignen für Caching in RESTful Designs.
Die Idee wäre, dass die Anwendung eine Ressource von Service2 abruft, die die Ressource zusammen mit einem ETag-Header zurückgibt (es könnte ein zuletzt geänderter Zeitstempel oder ein Hash sein). Die Anwendung würde dann diese Ressource zusammen mit dem ETag zwischenspeichern.
Wenn die Anwendung erneut mit der Ressource arbeiten muss, kann sie mit dem ETag-Header, den sie im Cache hat, ein HTTP GET an Service2 senden.
Dieser Ansatz funktioniert gut, wenn Sie sich nicht mit HTTP GET abmühen, um zu sehen, ob sich die Ressource geändert hat und ob Service2 einfach feststellen kann, ob sich die Ressource geändert hat (ohne sie laden zu müssen).
Der Vorteil ist, dass Service2 den Cache seiner Clients (Application) nicht ungültig machen muss, was möglicherweise keine sehr gute Praxis ist (und könnte schwierig sein, wenn Sie viele Clients haben).
>