3 Stimmen

Langlebige RESTful-Interaktionen

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

0 Stimmen

Eigentlich gibt es zwei Lösungen. Einfache Lösung: verwenden GET Geben Sie die Metadaten zurück, die Sie zu diesem Zeitpunkt haben, und setzen Sie den Cache-Lebensdauer-Header auf Null, wenn diese Daten noch generiert werden. Komplexe Lösung: Push verwenden, um die Metadaten an die Clients zu senden, wenn sie generiert werden... imo chaotisch, pita, nicht wert es. Verwenden Sie GET .

1voto

Darrel Miller Punkte 133891

Eine alternative Lösung, die in Ihrem Fall geeignet sein kann oder auch nicht, ist das Hinzufügen eines neuen Endpunkts mit der Bezeichnung "AnnotationRequests". Senden Sie das Dokument (oder einen Link dazu) an den Endpunkt "AnnotationRequests", und es sollte einen Standort zurückgeben (z. B. http://example.org/AnnotationRequest/2042 ), die es Ihrem Client ermöglicht, den Status des Prozesses abzufragen. Wenn der Prozess abgeschlossen ist, kann die "AnnotationRequest"-Darstellung einen Link zu dem fertigen Dokument enthalten.

Ein netter Nebeneffekt ist, dass Sie einen GET auf AnnotationRequests durchführen können, um die Dokumente zu sehen, die gerade bearbeitet werden. Es liegt an Ihnen zu entscheiden, wie lange Sie die AnnotationRequests aufbewahren wollen. Es kann sinnvoll sein, eine vollständige Historie darüber zu führen, wann sie angefordert wurden, von wem und wie lange sie jeweils gedauert haben, oder sie in regelmäßigen Abständen wegzuwerfen.

1voto

David Robbins Punkte 10000

Vielleicht möchten Sie sich informieren über Udi Dahan's nServiceBus .

0 Stimmen

Sieht interessant aus. Kennt jemand ein Java-Äquivalent?

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X