REST Basics ... sind die Demos der Weisheit letzter Schluss?

[Nersgatt]

Ich befasse mich auch grade mit den REST-Komponenten aus Delphi. Allerdings nur als Konsument von REST-Schnittstellen.
Bisher ist mir nichts aufgefallen, was mich an den Komponenten stören würde. Sie machen was sie sollen. Wenn richtig gemacht, landen die Daten direkt im ClientDataSet. Und andersrum, auch POST-Anfragen laufen hier bisher problemlos.

Das einzige, was mich wirklich stört, ist die Dokumentation (da nicht vorhanden). Da ist Nachholbedarf vorhanden.

[Nimral]

Hi ...

Zitat von Nersgatt:

Ich befasse mich auch grade mit den REST-Komponenten aus Delphi. Allerdings nur als Konsument von REST-Schnittstellen.
Bisher ist mir nichts aufgefallen, was mich an den Komponenten stören würde. Sie machen was sie sollen. Wenn richtig gemacht, landen die Daten direkt im ClientDataSet. Und andersrum, auch POST-Anfragen laufen hier bisher problemlos.

Das einzige, was mich wirklich stört, ist die Dokumentation (da nicht vorhanden). Da ist Nachholbedarf vorhanden.

Ich bin dan nicht ganz so glimpflich davongekommen. Meine Applikation lief anfangs, als sie noch sehr simpel aufgebaut war, ganz nett. Erste Brüche bekam der Glanz, als ich versucht habe, die Kommunikationsvorgänge unter der Haube zu ergründen. Das Implementieren der diversen OnEvent und OnTrace Methoden brachte praktisch keine Resultate, sie scheinen fast alle nicht implementiert zu sein. Oder man müsste das noch irgendwie aktivieren - und dan kommen wir zur völlig fehlenden Dokumentation. Ich konnte es nicht glauben. Ein bisschen was findet sich dann im Indy Projekt, aber das ist nicht viel, und noch ein bisschen was in der regulären XE Hilfe, die ich meinem XE5 aber erst aufzwingen musste, die reguläre Installation hat das irgendwie vergammelt.

Ein Konzept, von dem man überzeugt ist, und das man an die Welt verkaufen will, sieht anders aus, und die Stunden rinnen nur so dahin, ohne dass ich entscheidend weiterkomme bei meinem Hauptproblem: das Framework verliert immer wieder ohne ersichtlichen Grund seine Session - weit vor dem Timeout. Die nächste User-Aktivität baut wieder eine neue (mit Datenverlust auf der Serverseite), oder, was ich noch seltsamer finde, es wird für den selben Client und Browser eine zweite und sogar dritte Session eröffnet. Dabei dürfte man nach der reinen Lehre von REST ja gar keine Sessions brauchen - wobei das Konzept mit keiner Zeile darauf eingeht wie man ohne eine Session zu verwalten eine vernünftige Netzwerkapplikation schreiben kann, und die REST Demos ganz offenbar dieses Muss-Constraint auch einfach unter den Tisch fallen lassen.

Gruss Armin.

[Sir Rufo]

Ja das mit dem REST und einem ClientDataSet ist schon eine zauberhafte Sache.

Ich bekomme als Response 215.700 Bytes geliefert und das geht dann über den RestResponseDataSetAdapter in das ClientDataSet.
Beim Schließen der Anwendung kommt nach einer langen Verschnaufpause (und Auslastung eines Kerns):

Code:

---------------------------
Unexpected Memory Leak
---------------------------
An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TMoveArrayManager<System.JSON.TJSONValue> x 2, TMoveArrayManager<System.JSON.TJSONPair> x 6014
13 - 20 bytes: TJSONArray x 2, TJSONNumber x 6014, TJSONPair x 12028, TJSONObject x 6014, TJSONString x 18042, TStringBuilder x 24056
29 - 36 bytes: TList<System.JSON.TJSONValue> x 2, TList<System.JSON.TJSONPair> x 6014
37 - 44 bytes: Unknown x 18042
53 - 60 bytes: Unknown x 6014
117 - 124 bytes: Unknown x 6014

The sizes of unexpected leaked medium and large blocks are: 16428, 16428

---------------------------
OK   
---------------------------

Ohne den RestResponseDataSetAdapter gibt es diese Leaks nicht, somit ist die direkte Anbindung an ein DataSet nur euf den ARC Plattformen zu gebrauchen

[Nimral]

Zitat von Sir Rufo:

Ja das mit dem REST und einem ClientDataSet ist schon eine zauberhafte Sache.

...

Hi Sir,

ohne dass ich jetzt Deine persönliche Meinungsfreiheit einschränken will ... das hat mit meiner Frage nichts zu tun. Ich interessiere michfür - und habe Probleme mit - der grundlegenden Kommunikation und dem Session-Management, das es laut REST gar nicht geben darf. Nicht dass ich nicht auch mit Datenbanken arbeite, aber dieser Teil des Codes macht mir bisher keine Kopfschmerzen.

Nicht dass ich euren Input nicht schätze - vielleicht wäre er ein anderes Mal nützlich für mich - aber bitte bleibt in meinem Thread on Topic, oder macht einen eigenen.

Gruss Armin.

[Phoenix]

Naja.. das Thema ist halt ein Zweischneidiges Schwert.

Das REST (als Schnittstelle) Stateless ist heisst eigentlich auch, das ein Server, der über eine Stateless-Schnittstelle angesprochen wird, sich keine Informationen von woanders als vom Client holen darf, die gerade relevant sind.

Üblicherweise läuft Authentication nach dem Lehrbuch so ab:
Ein bestimmter REST-Service bekommt credentials (username, passwort) und erzeugt als Antwort ein Access-Token. In diesem Token sind alle informationen zum User und seinen Rechten verschlüsselt.
Andere Services, die eine Authorisierung benötigen, erwarten als einen Parameter ein solches Token.
Jeder dieser Service-Calls überprüft dann, ob der Token (noch) valide ist, und liest die anderen benötigten Informationen aus.
Es braucht hierbei keine Session, da der Client alle Informationen (verschlüsselt und damit nicht manipulierbar) verwaltet.


Das wird aber genau zu dem Zeitpunkt unpraktikabel, wenn sich z.B. Berechtigungen im laufenden System ändern können, und eine solche Berechtigungsänderung vor dem Ablauf des Tokens auch berücksichtigt werden muss.

In diesem Falle würde man in der Praxis schon eine Auswertung der Rechte auf dem Server implementieren (anhand der UserId im Token), und hätte hiermit schon zumindest offiziell keine REST-Schnittstelle mehr. Dann ist aber auch der Schritt nicht weit, an einem Token im Hintergrund auch noch andere Session-Informationen fest zu machen, die der Service nutzen kann.

Will heissen, die Theorie von REST ist da sehr klar und eindeutig, in der Praxis wirst Du jedoch kaum echtes REST nach dem Lehrbuch finden.
Irgend einen Server state wird es doch häufiger geben, insbesondere in Zusammenhang mit Authorization. Der Trick ist dann dabei eigentlich nur, da so gut abzukaspeln, das man das dem Service von aussen nicht mehr ansieht, und es für die Nutzung des Services auch nicht wirklich relevant ist.

[Nimral]

Zitat von Phoenix:

Naja.. das Thema ist halt ein Zweischneidiges Schwert.

...

Will heissen, die Theorie von REST ist da sehr klar und eindeutig, in der Praxis wirst Du jedoch kaum echtes REST nach dem Lehrbuch finden.
Irgend einen Server state wird es doch häufiger geben, insbesondere in Zusammenhang mit Authorization. Der Trick ist dann dabei eigentlich nur, da so gut abzukaspeln, das man das dem Service von aussen nicht mehr ansieht, und es für die Nutzung des Services auch nicht wirklich relevant ist.

Hi Phoenix,

meine Überlegungen gingen in die Richtung, ob das Design der REST Demos - alles in einer html Seite halten und mit der Sichtbarkeit von Abschnitten (div) arbeiten, was mich aus einigen Gründen (s.o.) stört, nicht genau da seine Ursache hat.

Ich möchte davon wenn möglich weg, aber die Frage ist, wenn ich beginne so gegen das REST Framework von Cantu, DeLong usw. zu arbeiten, ob das Framework mir dann überhaupt noch mehr nützt als schadet. Erfahrungssache: beginne gegen Dein Tool zu arbeiten, und Du hast einen mächtigen Feind

Im Kern scheint mir sowieso, dass das ganze REST Framework in Delphi in erster Linie mehr eine Luftnummer bzw. der Versuch, auf einem Buzzword Trittbrett zu fahren, ist. Was ich nützlich finde, ist der JSON Kommunikationskern, der bringt mich vorwärts. Der Rest ist mir eher lästig, und noch dazu ausgesprochen undurchsichtig (fehlende Doku waurde ja schon mehrmals erwähnt).

Gruss Armin.

[Phoenix]

Zitat von Nimral:

meine Überlegungen gingen in die Richtung, ob das Design der REST Demos - alles in einer html Seite halten und mit der Sichtbarkeit von Abschnitten (div) arbeiten, was mich aus einigen Gründen (s.o.) stört, nicht genau da seine Ursache hat.

Eher nicht.
Das hat sicher viel mehr damit zu tun, dass die Jungs keine Web-Application (HTML / JS) Cracks sind, und zum anderen sind das wirklich nur Demos.

Web-Client-Applications die mit einem Server kommunizieren baut man heutzutage komplett anders auf. Stichworte hier sind z.B. AngularJS oder Ember. Dazu schmeisst man dann ein eigenes Design oder wenn man von HTML und CSS nicht so die Ahnung hat z.B. einfach Twitter Bootstrap, ggf. mit einem der vielen Verfügbaren Themes rein.

Damit bist Du dann in der Lage, ohne herumschalten von irgendwelchsen Div's Deine Applikation im Browser mit sauberem MVC aufzusetzten. Dann hast Du auch im Client sogenannte 'Services' die Arbeit für Dich übernehmen, und im einfachsten Fall macht so ein 'Service' im Client dann nichts anderes, als im Hintergrund deinen REST-Server anzusprechen und die Antworten an Dein Client-Seitiges State-Model durchzureichen.

Durch den MVC-Ansatz hast Du dann auch im Client separate Views (kleine HTML- und ggf. CSS-Blöcke), in denen Du mittels einfacher Databinding-Ausdrücke Deine Model-Informationen reingibst (und wieder ausliest). Die meisten solcher Frameworks erlauben es dann auch, einzelne Module der Anwendung (also Models (JS), Views (HTML, CSS), Controller (JS) - und eben die nötigen Services (JS)) bei Bedarf nachzuladen. Somit hast Du nur die Informationen im Client, die Du auch wirklich brauchst (bzw. mal gebraucht hast).

Kurzum: Bei der Thematik am besten Server und Client wirklich getrennt betrachten. REST ist die Schnittstelle dazwischen, und auf beiden Seiten hast Du viele Freiheitsgrade. Und Demos sind Demos, und keine Templates für Real-World-Applikationen

[Nimral]

Zum Thema Authentifizierung ...

Zitat von Phoenix:

...

Andere Services, die eine Authorisierung benötigen, erwarten als einen Parameter ein solches Token.
Jeder dieser Service-Calls überprüft dann, ob der Token (noch) valide ist, und liest die anderen benötigten Informationen aus.
Es braucht hierbei keine Session, da der Client alle Informationen (verschlüsselt und damit nicht manipulierbar) verwaltet.

Ich konnte in Cantus und DeLongs Demos keine Spur von einem "verschlüsselten Token" finden, ich wüsste nicht, dass ein handelsüblicher Web-Client irgend etwas verschlüsselt oder sonstwie sicher aufbewahren kann. Aber mangels funktionierender Schnittstellen und Dokus (schon wieder das Unwort) bin ich nicht allzu weit unter die Haube des REST Projekts gekommen, bevor ich mich in Wäldern von undokumentierten Objekten verlaufen habe. Habe ich etwas übersehen?

Armin.