AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke REST-API längeres Warten auf Antwort

REST-API längeres Warten auf Antwort

Ein Thema von hschmid67 · begonnen am 26. Sep 2023 · letzter Beitrag vom 27. Sep 2023
Antwort Antwort
hschmid67

Registriert seit: 2. Jul 2012
Ort: Weilheim i. Obb.
71 Beiträge
 
Delphi 12 Athens
 
#1

REST-API längeres Warten auf Antwort

  Alt 26. Sep 2023, 10:38
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
Harald Schmid
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.421 Beiträge
 
Delphi 12 Athens
 
#2

AW: REST-API längeres Warten auf Antwort

  Alt 26. Sep 2023, 10:45
Du kannst ja die REST Requests auch asynchron laufen lassen. Dafür gibt es beim bordeigenen TRESTRequest die Methode ExecuteAsync.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.006 Beiträge
 
Delphi 2009 Professional
 
#3

AW: REST-API längeres Warten auf Antwort

  Alt 26. Sep 2023, 10:56
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
Michael Justin

Geändert von mjustin (26. Sep 2023 um 11:09 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von t2000
t2000

Registriert seit: 16. Dez 2005
Ort: NRW
232 Beiträge
 
Delphi 12 Athens
 
#4

AW: REST-API längeres Warten auf Antwort

  Alt 27. Sep 2023, 11:55
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.
Thomas
(Wir suchen eine(n) Entwickler(in) mit Ambitionen später ggf. die Softwarefirma zu leiten)
Aktuell nicht mehr. Aber ab vielleicht 2024/2025 wird das wieder sehr interessant!
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.638 Beiträge
 
#5

AW: REST-API längeres Warten auf Antwort

  Alt 27. Sep 2023, 15:03
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.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:26 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz