Langlebige RESTful-Interaktionen

Question

In meinem Team findet derzeit eine Diskussion statt, und ich wäre an anderen Meinungen interessiert. Nehmen wir an, wir haben einen RESTful-Webdienst, dessen Aufgabe es ist, Dokumente durch die Anwendung einer Reihe von Analysealgorithmen und -diensten zu annotieren. Die grundlegende Interaktion ist klar: Wir haben eine Ressource, die Dokumentensammlung; der Client POSTet ein neues Dokument an die Sammlung, erhält den URI des neuen Dokuments zurück und kann dann dieses Dokument GETEN docURI um das Dokument zurückzubekommen oder GET {docURI}/metadata um die allgemeinen Metadaten zu sehen, {docURI}/ne für benannte Entitäten, usw. Das Problem ist, dass einige der Analysen sehr lange dauern können. Angenommen, der Client ruft den Metadaten-URI ab, bevor die Analyse abgeschlossen ist, weil er in der Lage sein möchte, Teilergebnisse oder inkrementelle Ergebnisse auf der Benutzeroberfläche anzuzeigen. Die Wiederholung des GET in der Zukunft kann mehr Ergebnisse liefern.

Wir haben unter anderem folgende Lösungen diskutiert:

• Offenhalten der HTTP-Verbindung bis alle Analysen abgeschlossen sind (was nicht skalierbar zu sein scheint)
• mit content-length y accept-range Kopfzeilen, um inkrementelle Inhalte zu erhalten (aber wir wissen nicht im Voraus, wie lang der endgültige Inhalt sein wird)
• die Bereitstellung von einen Atom-Feed für jede Ressource, so dass der Client Aktualisierungsereignisse abonniert Ereignisse abonniert, anstatt die Ressource einfach zu GETTEN der Ressource (scheint übermäßig kompliziert und möglicherweise ressourcenhungrig, wenn es viele aktive Dokumente gibt)
• nur mit GET zurück was auch immer zu diesem Zeitpunkt verfügbar ist (aber es bleibt bleibt das Problem, dass der Client weiß, wann wir endlich fertig sind) [bearbeitet, um den Hinweis auf die Idempotenz nach den Kommentaren zu entfernen] .

Gibt es Meinungen oder Vorschläge für alternative Möglichkeiten zur Handhabung von langlebigen oder asynchronen Interaktionen in einer RESTful-Architektur?

Ian

Answer 1

Ich würde es folgendermaßen umsetzen:

1) Kunde fordert Metadaten an
2) Der Server gibt entweder die aktuellen Daten zurück (wenn sie bereits verfügbar sind) oder die NotReady-Markierung
3) Der Client fragt den Server, wann die Daten verfügbar sein werden (dieser Schritt kann mit dem vorherigen zusammengelegt werden)
4) Der Server gibt das Zeitintervall zurück (möglicherweise gibt es eine Heuristik für die Gesamtzahl der ausgeführten Aufträge usw.)
5) Der Kunde wartet eine bestimmte Zeit und geht zu Schritt 1 über

Auf diese Weise können Sie den Kunden so schnell wie möglich Daten zur Verfügung stellen. Sie können die Serverauslastung beeinflussen, indem Sie das in Schritt 4 angegebene Verzögerungsintervall anpassen.)

Answer 2

Bereitstellung eines Atom-Feeds für jede Ressource, so dass der Client Aktualisierungsereignisse abonniert, anstatt die Ressource einfach nur zu GETEN (scheint übermäßig kompliziert und möglicherweise ressourcenintensiv zu sein, wenn es viele aktive Dokumente gibt)

Haben Sie bedacht SUP ?

Wenn die Abfrage eine Option ist, warum sollte man sich dann mit einem Feed beschäftigen? Warum lassen Sie die Clients nicht einfach die Ressource selbst abfragen?

Könnten Sie unnötige Umfragen einsparen, indem Sie eine geschätzte Zeit für den Abschluss der Analysen angeben?

Answer 3

Utilice HTTP 202 Akzeptiert .

Besuchen Sie auch RESTful Webdienste - Dort habe ich von den oben genannten Dingen erfahren.

Answer 4

• einfach die Idempotenz ignorieren und GET das zurückgeben lassen, was gerade verfügbar ist (aber es bleibt immer noch das Problem, dass der Client weiß, wann wir endlich fertig sind).

Bedeutet ein GET, das im Laufe der Zeit unterschiedliche Ergebnisse liefert, wirklich, dass es nicht idempotent ist? Die Spezifikation sagt:

Methoden können auch die Eigenschaft der "Idempotenz" haben, so dass (abgesehen von Fehler- oder Ablaufproblemen) die Nebenwirkungen von N > 0 identischen Anfragen die gleichen sind wie bei einer einzigen Anfrage

Das heißt, dass mehrere GET-Aufrufe unterschiedliche Ergebnisse liefern können, solange die Aufrufe selbst frei von Nebeneffekten sind.

In diesem Fall könnte Ihre REST-Methode vielleicht die bedingten GET- und Caching-Mechanismen verwenden, um anzuzeigen, wann sie fertig ist:

• Während die Analyse im Gange ist, wird eine GET {docURI}/metadata Antwort haben könnte:
  • un Expires Kopfzeile auf einige Sekunden in der Zukunft eingestellt.
  • pas de ETag Kopfzeile.
• Sobald die Analyse abgeschlossen ist, haben die Antworten für diese Ressource:
  • pas de Expires Kopfzeile.
  • un ETag . Spätere Anfragen bei der ETag sollte zurückkehren 304 Not Modified .

Beachten Sie auch die anderen Antwort-Header, die an der Zwischenspeicherung beteiligt sind, nicht nur Expires.

Dies "fühlt" sich an wie ein RESTful-Entwurf - man kann sich vorstellen, dass ein Webbrowser das Richtige tut, wenn er aufeinanderfolgende Anfragen an diese Ressource stellt.

Answer 5

"GET soll nur das zurückgeben, was gerade verfügbar ist", ist sehr sinnvoll. Nur sollte man bei Umfragen nicht ständig etwas zurückgeben, was sie schon wissen. Die Antworten werden bei jeder Abfrage länger.

Sie müssen Ihnen in der GET-Anfrage mitteilen, "was ich bisher gesehen habe". Dadurch erhalten Sie Idempotenz. Wenn sie nach Chunk 1 fragen, erhalten sie immer die gleiche Antwort. Sobald sie Chunk 1 gesehen haben, können sie nach Chunk 2 fragen.

Die Antwort wird nicht größer. Es werden mehr Teile verfügbar. Ein GET auf "Sammlungsebene" liefert die Größe der Antwort. Sie haben "Detail-Level" GETs für jedes verfügbare Teil.

Im Wesentlichen handelt es sich dabei um einen Algorithmus wie bei der TCP/IP-Bestätigung. Wenn ein Teil bestätigt wird, sendet man den nächsten Teil. Wenn es ein nächstes Stück gibt, senden Sie andernfalls eine 200 - nichts Neues zu berichten.

Das "Problem, dass der Kunde weiß, wann wir endlich fertig sind", ist unwägbar. Sie können es nicht wissen, und Sie können nicht vorhersagen, wie lange es dauern wird.

Sie wollen nicht, dass sie "busy waiting" machen - abfragen, ob Sie schon fertig sind - das ist eine ziemlich große Belastung für Ihren Server. Wenn sie ungeduldig sind. Sie können ihre Anfragen drosseln. Sie können ihnen eine Nachricht schicken, dass sie in x Sekunden zurückkommen sollen, wobei x immer größer wird.

Sie können sogar einen Unix-ähnlichen Scheduler-Algorithmus verwenden, bei dem die Punktzahl sinkt, wenn sie abfragen, und steigt, wenn sie X Sekunden lang nicht abfragen.

Die Alternative ist eine Art Warteschlange, in die Sie die Ergebnisse zurückschicken. Dazu müssten sie einen URI bereitstellen, den Sie POSTen können, um ihnen zu sagen, dass Sie fertig sind.

Oder sie verwenden Atom für eine leichtgewichtige Polling-Architektur. Während Atom komplex erscheint - und es beinhaltet immer noch Polling - geben Sie eine minimale Atom-Antwort ("noch nicht geändert"), bis Sie fertig sind, wenn Sie ("neue Ergebnisse") liefern, damit sie die real Schwergewicht bekommen. Dies ist für alles oder nichts, anstelle der inkrementellen Antwort Technik oben.

Sie können sich das GET auf "Sammlungsebene" auch als Ihren Atom-Status für den Prozess als Ganzes vorstellen.