REST-API längeres Warten auf Antwort

[hschmid67]

Hallo zusammen,

ich wollte mal Eure Meinung und Erfahrung erbitten zu folgender Situation:

Ich habe eine REST-API (XData-Server von TMS) und habe da einzelne Endpunkte, die eine längere Ausführungszeit brauchen. Ich kann nicht vorhersagen, wie lange. In manchen Befehlen wird eine Anfrage in eine serielle Queue geschoben und erst wenn die Anfrage dran ist - je nachdem wie voll die Queue ist - liegt das Ergebnis vor. Ungern möchte ich aber den REST-Aufruf, die Antwort darauf so lange laufen lassen. Muss ich da ein anderes Protokoll nehmen (WebSocket?), oder gibt's einen guten Weg, dem Client eine Antwort zu schicken, wenn sie eben bereit ist.

Wie machen manche Web-Dienste das, wenn Sie nach meinem Aufruf einer Funktion (z.B. Rechnungserstellung, oder Rechnungsdaten bei einem Telekom-Anbieter) irgendwann dann schreiben: "Jetzt liegt die Rechnung zum Download vor." Ist das dann ein regelmäßiges Polling?

Ziel wäre es für mich, dem Frontend eine möglichst schnelle Antwort zu geben und dann, wenn weitere Ergebnisse vorliegen, diese nach und nach zurückzuliefern und zu ergänzen...

Viele Grüße
Harald

[Uwe Raabe]

Du kannst ja die REST Requests auch asynchron laufen lassen. Dafür gibt es beim bordeigenen TRESTRequest die Methode ExecuteAsync.

[mjustin]

WebSockets sind eine Möglichkeit, den Client über die Fertigstellung zu informieren, und auch geeignet um die Ergebnisse zurück an den Client zu senden.
Der REST-Aufruf liefert dann lediglich eine Quittung, dass der Request angenommen wurde.

Anstatt Web Sockets könnten, um ohne Polling zu arbeiten, auch Server-Sent-Events (SSE) verwendet werden, diese verwenden Standard HTTP (ohne Upgrade).
Dann wartet der Client bis ein Event vom Server anzeigt, dass die Ergebnisse abgeholt werden können. SSE Client-Beispiel: https://github.com/michaelJustin/indy-sse-jaxrs

[t2000]

Wir machen das so (wie auch mjustin geschrieben hat)

Die Anfrage wird an den (TMS-XData) REST-Server gesendet. Dieser schiebt die Ausführung der Anfrage in einen neuen Thread und antwortet direkt, dass er die Anfrage erhalten hat.
Sobald die Anfrage erledigt ist, schickt der Server über WebSocket ein Signal, dass das Ergebnis abgeholt werden kann.

Wenn du mit TMS arbeitest, kannst du das mit deren WebSocket machen. Wir setzen aktuell esegece.com ein.

[Phoenix]

Neben Polling und aktiver Benachrichtigung über Websockets gibt es auch noch sogenannte Webhooks.

Diese würde ich grundsätzlich bevorzugen, denn sie benötigen auf beiden Seiten keine permanenten Ressourcen und sind stateless, und lassen sich somit deutlich einfacher skalieren.

Da gibt es 2 generelle Ansätze:
Der Client-Dienst schickt dem Server-Dienst die Aufgabe mit einer Id (z.B. xyz), und bekommt sofort die Antwort dass die Anfrage angenommen wurde.
Der Server-Dienst verarbeitet die Anfrage.
Ist er fertig, ruft er eine ihm bekannte URL auf dem Client-Dienst auf und sagt diesem somit aktiv, das Job xyz fertig ist. Er schickt nicht das Ergebnis mit, sondern das ist nur ein ganz kurzes "Hey, xyz ist fertig!"
Der Client-Dienst kann jetzt das Ergebnis abrufen und damit weiter machen.

Der zweite Ansatz ist so ähnlich, nur kennt der Server-Dienst die Url des Client-Dienstes nicht.
Der Client-Dienst gibt also beim Aufruf nicht nur die Job-Id mit, sondern die komplette Url, die der Server-Dienst aufrufen soll. z.B. "https://{ip}:{port}/webhooks/job-fertig/xyz" <- da steckt die job-id xyz auch drin
Nach dem Abarbeiten ruft der Server-Dienst also einfach immer die übergebene Url auf, und meldet somit das er fertig ist, ohne dass er die Adresse oder gar eine Id vorher kennen müsste. Der Client kann also komplett selber bestimmen, wie er benachrichtigt werden will und es sind keine Änderungen am Server-Dienst nötig, wenn der Client irgendwann mal z.B. einen weiteren Parameter möchte.