Wir haben einige Ressourcen auf einem REST-Server, der wie folgt strukturiert ist:
/someResources/foo /someResources/bar /someResources/baz Dabei ist someResource eine Serverdarstellung eines weit entfernten verteilten Objekts.
Wir möchten dem Server mitteilen, dass er seine Darstellung dieses "verteilten Objekts" aktualisieren soll, indem er es im Netzwerk & amp; Aktualisieren des Cache des Servers, d. h. wir können den neuen Wert nicht einfach PUT setzen.
Was ist der saubere REST-Weg dazu?
a) Soll an eine /refreshes/ eine neue "Refresh-Anfrage" gesendet werden?
b) Soll PUT (mit einem leeren Dokument) an http://ip/someResources ?
c) Noch etwas?
Ich mag (a) wie es uns eine ID geben wird, um & amp; verfolgen Sie den Refresh-Befehl, aber besorgt, dass wir zu viele Ressourcen erstellen. Irgendwelche Tipps?
Ich würde mit dem Ressourcenansatz "Refreshes" fortfahren. Dies hat zwei große Vorteile.
(a) Wie bei den Lebenszyklusoperationen (Kopieren, Klonen, Verschieben) ist der Zweck der Aktualisierung orthogonal zur Funktion der zugrunde liegenden Ressource und sollte daher vollständig getrennt sein.
(b) Es gibt Ihnen eine Möglichkeit, den Fortschritt der Aktualisierung zu überprüfen - der externe Status der Aktualisierungsressource würde Sie mit einem Attribut "Status" oder "Fortschritt" versorgen.
Wir haben die Life-Cycle-Operationen auf diese Weise implementiert und die Trennung von Bedenken ist ein großes Plus an Design.
Eine andere Möglichkeit, dies zu bewerkstelligen, besteht darin, dem Server zu erlauben, seine Darstellung der Ressource für eine gewisse Zeit zu cachen, nur um den realen Zustand nach einer Zeitüberschreitung zu überprüfen. In diesem Modell ist Ihr Server wirklich eine Zwischenspeicherungsressource und sollte dem HTTP-Caching-Verhalten folgen, siehe hier für mehr Details. Im Folgenden zitiere ich einen sehr relevanten Abschnitt, der davon redet, dass der Client die zwischengespeicherten Werte überschreibt.
13.1.6 Clientgesteuertes Verhalten
Während der Ursprungsserver (und in geringerem Maße dazwischenliegende Caches aufgrund ihres Beitrags zum Alter einer Antwort) die primäre Quelle für Ablaufinformationen sind, muss der Client in einigen Fällen möglicherweise die Entscheidung eines Caches über die Rückgabe eines zwischengespeicherten Inhalts steuern Antwort ohne es zu validieren. Clients verwenden dazu mehrere Direktiven des Cache-Control-Headers.
Der Antrag eines Kunden kann das maximale Alter angeben, das er von einer nicht validierten Antwort akzeptieren möchte; Wenn Sie einen Wert von 0 angeben, werden die Caches gezwungen, alle Antworten erneut zu validieren. Ein Client kann auch die Mindestzeit angeben, die vor Ablauf einer Antwort verbleibt. Beide Optionen erhöhen die Beschränkungen für das Verhalten von Caches und können die Annäherung des Cache an die semantische Transparenz nicht weiter entspannen.
Ein Kunde kann auch angeben, dass er veraltete Antworten bis zu einem gewissen Grad an Veralterung akzeptiert. Dadurch werden die Einschränkungen für die Caches gelockert, wodurch möglicherweise die angegebenen Beschränkungen für die semantische Transparenz des Ursprungsservers verletzt werden. Dies kann jedoch erforderlich sein, um den getrennten Betrieb zu unterstützen, oder bei schlechter Konnektivität eine hohe Verfügbarkeit.
Chris
HTTP-Caching scheint dies zu ermöglichen. Ссылка
Setze die Kopfzeile max-age = 0 und dies weist den Server an, dass der Client eine neue Version haben möchte. Auf diese Weise können Sie einfach weiterhin ein GET verwenden.
Tags und Links api rest http api-design