![]() |
Client-Units für JSON-REST-Services erzeugen
Hallo,
ich habe mich gerade einmal ein wenig umgesehen und suche für Delphi eine einfache Möglichkeit aus fertigen OpenAPI/Swagger-Dateien fertige Client-Schnittstellen erzeugen zu lassen (ähnlich wie das bei SOAP ja auch funktioniert). Gibt es da schon etwas fertiges? Die meisten Codegeneretoren bieten mir von Java bis curl alles mögliche an, aber kein Delphi. Generell ist es ja auch kein Problem solche Schnittstellen selbst zu tippen, doch je nach Umfang wird das doch sehr nervend. Kennt da jemand etwas sinnvolles? Gibt es da schon ein Projekt für openapi-generator oder irgendwas anderes was einem das Leben ein wenig erleichtert? Vielen Dank schonmal für Antworten. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Mich kannst du allerdings auch in das Lager der Nachfragenden zählen. Hatte nur noch keine Zeit, selbst sowas zu schreiben. |
AW: Client-Units für JSON-REST-Services erzeugen
Me too. ;-)
Ich habe aktuell ein Projekt an der Backe, da wäre sowas sehr praktisch gewesen. Nja, es hätte vielleicht zwei Stunden Arbeit eingespart, wenn's hoch kommt. Aber halt langweilige Arbeit. Nächste Woche habe ich Urlaub, vielleicht habe ich ja dann soviel Langeweile, dass ich mich da mal drangebe. Die geplante Reise fällt ja aus bekannten Gründen ins Wasser... |
AW: Client-Units für JSON-REST-Services erzeugen
Ja und auch hier würd ich so was benötigen.
|
AW: Client-Units für JSON-REST-Services erzeugen
Dann habe ich immerhin nichts übersehen. Aber schön das es Nachfrage gibt. Ich habe mich selbst einmal nur kurz mit dem Projekt unter
![]() beschäftigt (alleine weil ich es für andere Sprachen auch nutze). Und nach kurzen Studien sieht das genau so aus, als könnte man damit solche Dateien generieren. Ich werde mich in den nächsten Tagen immer mal wieder daran setzen und schauen ob ich etwas laufendes zustande bekomme. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Ich hatte mich vor einem Jahr mal mit den Java-CodeGen Sourcen auseinander gesetzt. Dachte wenn ich die Module einer bestehenden Sprache kopiere (z.B. C#) müsste ich doch evtl. nur noch ein paar Templates anpassen. Es scheiterte dann daran, dass ich das entsprechende Java-Projekt nicht ans laufen gebracht habe. Ich hatte dann einen Generator geschrieben, der aus der Modelbeschreibung der Swagger HTML-Dokumentation (einfach nur Text), Klassen generiert. Aber direkt aus der JSON OpenAPI Beschreibung zu generieren wäre natürlich viel besser und zukunftssicherer. Gibt es hier vielleicht einen JAVA-Experten, der interessierte Delphi-Entwickler dabei unterstützen könnte, das CodeGen-Projekt um Delphi zu erweitern? Ciao HeZa |
AW: Client-Units für JSON-REST-Services erzeugen
Ich werde meine Erfahrungen auf jeden Fall teilen. Bisher sieht es vielversprechend aus.
Nur bitte nicht erwarten, das es morgen fertig ist :) |
AW: Client-Units für JSON-REST-Services erzeugen
Wir bei der Generative Software GmbH aus Freiburg im Breisgau entwickeln gerade im Kundenauftrag einen REST-Service-Generator für Delphi der OpenAPI-Input verarbeitet. Der generierte Code nutzt das MARS CURIOSITY Framework (
![]() |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
|
AW: Client-Units für JSON-REST-Services erzeugen
Habe genau sowas auf der Arbeit gebaut. Funktioniert eigentlich ziemlich gut.
Aber ich schätze das kann ich euch wahrscheinlich nicht so ohne weiteres geben :( |
AW: Client-Units für JSON-REST-Services erzeugen
Bei mir ist es ähnlich. Ich muss auch nachfragen oder mache es privat "nochmal". Es funktionieren diverse Dinge auch schon, wie das erzeugen der Objekte, die Rümpfe der Methoden. Bei mir geht es jetzt daran, eine schöne Implementierung für die Methoden zu finden und auch solche Dinge wie Authentifizierung zu unterstützen (wahrscheinlich per event).
|
AW: Client-Units für JSON-REST-Services erzeugen
Hallo Zwixx,
Zitat:
![]() Ciao HeZa |
AW: Client-Units für JSON-REST-Services erzeugen
Bei mir ist es eine Erweiterung des openapi-generator
|
AW: Client-Units für JSON-REST-Services erzeugen
Liste der Anhänge anzeigen (Anzahl: 1)
So, ich habe mich dazu entschieden das ganze (privat) nochmal zu machen. Dabei habe ich auch gleich einige Fehler im Design behoben.
Als Beispiel für eine OpenAPI-Datei habe ich einfach einmal die API von ebay ausgesucht, da sie mir am ausreichend komplex erschien. ![]() Der Sourcecode den es bisher erzeugt ist fast Syntaxmäßig valide (was aber nicht heisst, das es funktioniert :) ), bis auf eine Methode (getSalesTax). Sie wird offenbar gleichzeitig als POST und als GET verwendet. So eine Konstruktion ist nicht schön, aber durchaus valide. Deswegen muss ich mir da etwas einfallen lassen, wie ich solche Doppeldeutigkeiten auflöse. Quellcode auf Github: ![]() Eine Beispieldatei was dabei heraus kommt wenn ich das erzeuge habe ich angehängt. |
AW: Client-Units für JSON-REST-Services erzeugen
Danke dafür, ist sehr interessant :thumb:
|
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Warum hast du dich entschieden, für jeden Aufruf jeweils eine neue Instanz von TRESTRequest, TRestClient und TRESTResponse zu verwenden? Gab es dafür gewichtige Gründe? Instinktiv hätte ich den Request als Klassenvariable angelegt und vor jeden Ausführen geresetet. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Folgende Fehler habe ich heute noch behoben: Arrays werden jetzt korrekt beachtet Request wird nur einmal erstellt und immer wieder verwendet. Fehler mit ToString bei Strings behoben Das Problem mit dem getSalesTax existiert immer noch. Das sehe ich mir mal als nächstes die Tage an. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Weil in der HTML-Doku steht dazu ja nichts (oder ich sehe es nicht, weil der Kaffee noch nicht wirkt). ![]() |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Danach werde ich das ganze mal testen ob es überhaupt funktioniert, wenn das klappt dann könnte ich mal die erste alpha releasen. Ich weis noch nicht, wie ich mit Authentifizierung umgehe. Ich habe ja überall die "vor" und "danach" Methoden eingebaut, so dass jeder seine eigenen Methoden zur Authentifizierung machen kann. Oder ich sehe ein paar einfache Dinge vor, wie Basic Auth und OAuth2 beispielsweise. Das wenn diese Zugriffsmethoden im openapi erwähnt werden, das man so eine Art Supportmethoden bekommt, die einem helfen das zu implementieren. |
AW: Client-Units für JSON-REST-Services erzeugen
Ich habe es heruasgefunden woran es liegt. Es wird im openapi.yaml mit folgenden response beschrieben:
Code:
Ich gehe davon aus, das man wenn keine response vorhanden ist, es eine procedure ist, wenn es einen Rückgabewert gibt, eine function ist. In diesem Falle wird sie aber als beides beschrieben. Sie kann einmal ein Objekt zurückgeben, einmal nicht.
"responses": {
"200": { "description": "Success", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/SalesTax" } } } }, "204": { "description": "No content" }, Was macht das für einen Sinn? Ich werde sehen, wie ich das behandeln kann. |
AW: Client-Units für JSON-REST-Services erzeugen
Hmm..
Zitat:
Es gibt bei Vorhandensein (200) von Daten ein Object zurück, ansonsten (204) eben NIL. Somit sollte es immer eine Funktion sein, es muss halt geprüft werden, ob NIL zurück gegeben wurde. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Als nächstes steht dann an noch einige Methoden ein wenig aufzuräumen und in andere Methoden auszulagern. Dann aber kann ich an die ersten Tests gehen. |
AW: Client-Units für JSON-REST-Services erzeugen
So, bisher ist die Syntax richtig, ich habe noch ein wenig aufgeräumt und es scheint zu funktionieren. Ich habe selbst kein ebay-developer-account und auch keine Möglichkeit das so einfach zu testen :) Ich werde mir aber mal was suchen, wo ich sehen kann ob das so geht wie ich möchte (und wenn ich mir selbst eben einen Service zusammenbaue).
Hier der erzeugte Quellcode aus dem Beispiel bisher: ![]() Verbesserungen die ich noch nicht beachtet habe: * Die Objekte sollten wieder automatisch freigegeben werden, die an den jeweiligen Objekten hängen. So ähnlich wie dies auch beispielsweise die WebService-Importer macht. * Methoden für Basic Auth und Oauth2, die zumindest den Token fest setzen lassen das man diesen nicht immer manuell über die Events setzen muss. |
AW: Client-Units für JSON-REST-Services erzeugen
Zitat:
Hallo zusammen. Wenn immer derselbe Client/Request/Response verwendet wird - wie verhält es sich bei massenhaft Requests? Wird das irgendwo gecacht? Angenommen es wird ein Request abgesetzt und es dauert sehr lange bis eine Response kommt. Kurz darauf wird der Request für eine andere Funktion aufgerufen. Gefühlsmässig würde ich pro Anfrage den Request und die Response erzeugen und am Ende wieder freigeben. Und die Response und Request jeweils der vorhandenenen RestClient Instanz zuweisen. Was meint Ihr? Beziehungsweise was gibt es für Erfahrungen? |
AW: Client-Units für JSON-REST-Services erzeugen
Standardmäßig nein,
außer es wurde extra eingebaut/aktiviert. Entweder das REST-Framework merkt sich die reinkommenden Parameter und das Ergebnis und bei Gleichheit wird ohne Aufruf Methode direkt das Ergebnis ausgeliefert. Aber wenn, dann wirst du das erst explizit aktivieren müssen, denn Funktionen alla "gib mit den aktuellen Wert/Summe/Zeit/..." sollen ja nicht immer das selbe Ergebnis liefern. Im DataSnap / RAD-Server gibt es auch einen Cache im Protokoll. So können Parameter/Daten vor Aufruf der Methode (vor dem Request) dort reingeladen werden, der es könnte das Result dort abgelegt werden (vor allem wenn viele Date/Werte raus kommen und das nur teilweise, unsortiert oder verzögert vom Client abgerfen wird) und wenn die Daten schon im Cache sind, dann könnte der nächste Aufruf das vorher prüfen und dann seine Arbeit abbrechen. Ich weiß aber nicht wie man diese Funktion nutzen kann. (hab's erst vor Kurzem bemerkt, als ich es im Protokollaufbau sah) Du kannst auch in deine Funktion sowas einbauen. Zu Beginn in einen Cache schauen und wenn möglich dann den Rest der Methode überspringen.
Delphi-Quellcode:
Und falls Result auch ein LeerString sein kann und der Cache sowas nicht speichern kann,
var Cache: TStringList; // möglichst Sorted=True oder ein sortiertes/inditiertes TDictory<T>
funktion TMyServerMethods.MyMethod(Param: string): string; begin //if Param = '' then // Exit(''); Result := Cache.Values[Param]; if Reuslt <> '' then Exit; ... Cache.Values[Param] := Result; end; dann muß man entweder damit Leben, dass die Methode in diesem Fall dennoch ausgeführt wird, oder man muß das Speichern/Auslesen bissl anpassen.
Delphi-Quellcode:
funktion TMyServerMethods.MyMethod(Param: string): string;
begin Result := Cache.Values[Param]; if Reuslt <> '' then begin if Reuslt = ' ' then Reuslt := '': Exit; end; ... if Result = '' then Result := ' '; Cache.Values[Param] := Result; end;
Delphi-Quellcode:
funktion TMyServerMethods.MyMethod(Param: string): string;
begin i := Cache.IndexOfName(Param); if i >= 0 then Exit(Cache.ValuesByIndex[i]); ... if Result = '' then begin Cache.Values[Param] := ''; Cache.Add(Param + Cache.NameValueSeparator); end else Cache.Values[Param] := Result; end; Etwas problematisch sind auch Fälle, wo der Request etwas dauert und mehrmals zeitgleich gleiche Anfragen rein kommen... Entweder man baut eine Synchronisierung ein (CriticalSection) oder selbst mit Cache sind die ersten Anfragen (auch nochmal nachdem der "alte" Wert aus dem Cache flog) somit gleichzeitig, da zu Beginn noch nichts im Cache war und es wird paralell mehrfach verarbeitet würde. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz