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

**Nimral**

Hi allseits,

ich habe ein wenig mit den REST Demos von Marco Cantu und Mat deLong in Delphi RAD Studio XE5 gespielt. Was mir daran nicht gefällt: im Prinzip wird die ganze Arbeit (login, was danach kommt) von einer einzigen Webseite abgewickelt. Je nachdem was die JSON Calls zum Server ergeben, werden verschiedene div's an- und aus geknipst.

Ich finde den Lösungsansatz aus mehreren Gründen unpraktisch:

- die Webseite verrät für meinen Geschmack viel zu viel an User, die noch nicht einmal angemeldet sind
- die vor- und zurück Buttons der Browser werden bedeutungslos
- je komplexer die Appliation wird, umso unübersichtlicher wird die html Seite

Ich bin jetzt unsicher, ob dieses Verhalten ein Teil des REST Konzepts ist (das Lesen der Dissertation von Roy Fielding fand ich eher verwirrend als erhellend), oder ob die Embarcadero Mannen sich einfach entschieden haben, ihre Demos so aufzubauen.

Wer kann dazu etwas sagen?

Thx

Armin.

**Daniel**

Wie sich die Kommunikation mit einem REST-Server gestaltet, hängt individuell vom jeweiligen Server ab bzw. den Vorstellungen des jeweiligen Anbieters: Facebook beispielsweise verlangt ein Login über einen Web-View bei nativen Anwendungen. Das ist dort der offizielle Weg, er auch in den Demos gezeigt wird.
Andere Server verlangen vielleicht nur eine einfache Authentifizierung und oftmals gibt es auch mehrere Wege zum Ziel.

Die REST-Demos, die XE5 und folgenden Versionen beiliegen, dienen auch eher zur Demonstration der REST-Komponenten als einen vollständigen Überblick über REST zu geben.

Mit der Dissertation - ich habe sie gelesen - hast Du aber eigentlich ein gutes Dokment and er Hand, welches die Ideen hinter REST erläutert. Wenn Du konkrete Fragen hast, können wir diese hier gern erörtern.

**EgonHugeist**

Alternativen giebt es auch im OpenSource-Bereich, welche DataSnap und dem ganzen Gedöhns in jeder Hinsicht das Wasser reichen und in Sachen Performance WEIT WEIT schneller sind:

http://synopse.info/fossil/wiki/Synopse+OpenSource

Das Projekt selbst hat auch schon die Aufmerksamkeit von Marco Cantu persönlich erreicht, da mORMot mit fast der Hälfte das Speichers und unglaublicher Performance brilliert...

**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 Daniel,

Zitat von Daniel:

Die REST-Demos, die XE5 und folgenden Versionen beiliegen, dienen auch eher zur Demonstration der REST-Komponenten als einen vollständigen Überblick über REST zu geben.

Mit der Dissertation - ich habe sie gelesen - hast Du aber eigentlich ein gutes Dokment and er Hand, welches die Ideen hinter REST erläutert. Wenn Du konkrete Fragen hast, können wir diese hier gern erörtern.

danke für das Angebot, das nehme ich gerne an. Die Dis erläutert also die Ideen, die Demos zeigen eine Implementierungsmöglichkeit, aber die Mitte zwischen den beiden ist hohl: die Dis schlägt keine konkreten Implementierungsen vor, die Demos zeigen außer bei der Bezeichnung REST an keiner Stelle, inwiefern sich ihre Wege mit der Dissertation vertragen und inwiefern man einfach eine JSON gestützte Applikation geschrieben hat, die man dann unter dem Buzzword "REST" in die Welt setzt.

Beginnen wir mal mit der meiner Meinung nach ärgsten Grauzone: REST verlangt statelessness (5.1.3). Die Delphi Implementierung des TDSSessionManager Singleton macht genau das nicht.

Gruss Armin.

**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):

markieren

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.