Client-Units für JSON-REST-Services erzeugen

[Zwixx]

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.

https://developer.ebay.com/api-docs/...ources/methods

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: https://github.com/Zwixx/delphi-openapi-generator

Eine Beispieldatei was dabei heraus kommt wenn ich das erzeuge habe ich angehängt.

[Rollo62]

Danke dafür, ist sehr interessant

[TiGü]

Zitat von Zwixx:

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.

Sehr cool!

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.

[Zwixx]

Zitat von TiGü:

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.

Wie gesagt, der Quettext mag syntaktisch richtig sein, schön ist er nicht. Das ist beispielsweise einer der Punkte, die man noch besser machen sollte.

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.

[TiGü]

Zitat von Zwixx:

Das Problem mit dem getSalesTax existiert immer noch. Das sehe ich mir mal als nächstes die Tage an.

Fällt das so aus dem OpenAPI-Generator raus?
Weil in der HTML-Doku steht dazu ja nichts (oder ich sehe es nicht, weil der Kaffee noch nicht wirkt).
https://developer.ebay.com/api-docs/...ds/getSalesTax

[Zwixx]

Zitat von TiGü:

Fällt das so aus dem OpenAPI-Generator raus?
Weil in der HTML-Doku steht dazu ja nichts (oder ich sehe es nicht, weil der Kaffee noch nicht wirkt).
https://developer.ebay.com/api-docs/...ds/getSalesTax

Ja, irgendwas ist allerdings an dieser Funktion komisch. Da nur gerade diese nicht funktioniert. Aber das bekomme ich schon noch raus was da schief läuft.

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.

[Zwixx]

Ich habe es heruasgefunden woran es liegt. Es wird im openapi.yaml mit folgenden response beschrieben:

Code:

        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/SalesTax"
                }
              }
            }
          },
          "204": {
            "description": "No content"
          },

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.

Was macht das für einen Sinn?

Ich werde sehen, wie ich das behandeln kann.

[HolgerX]

Hmm..

Zitat von Zwixx:

Ich habe es heruasgefunden woran es liegt. Es wird im openapi.yaml mit folgenden response beschrieben:

Code:

        "responses": {
          "200": {
            "description": "Success",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/SalesTax"
                }
              }
            }
          },
          "204": {
            "description": "No content"
          },

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.

Was macht das für einen Sinn?

Ich werde sehen, wie ich das behandeln kann.

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.

[taveuni]

Zitat von Zwixx:

Zitat von TiGü:

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.

Folgende Fehler habe ich heute noch behoben:
Request wird nur einmal erstellt und immer wieder verwendet.

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?

[himitsu]

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:

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;

Und falls Result auch ein LeerString sein kann und der Cache sowas nicht speichern kann,
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.