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:

Zitat von Daniel (Beitrag 1277052)

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:

Zitat von Nersgatt (Beitrag 1277075)

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   
---------------------------

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

[Nimral]

Zitat:

Zitat von Sir Rufo (Beitrag 1277089)

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

...

:kotz:

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:

Zitat von Phoenix (Beitrag 1277129)

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.

[Nimral]

Zum Thema Authentifizierung ...

Zitat:

Zitat von Phoenix (Beitrag 1277129)

...

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.

[Phoenix]

Zitat:

Zitat von Nimral (Beitrag 1277134)

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]

Hi Sebastian,

danke für die Info und Deine Meinung. Ich denke aber, dass Du das REST Framework, das in XE5 implementiert wurde, unterschätztst. Dass man damit nicht in der Lage wäre, Amazon oder Ebay abzuwickeln, wurde bereits fundiert bewiesen. Meine Applikationen sind um einige Größenordnungen kleiner. Auch die Datenbankanbindung ist - gemessen an dem was man mit Datenbanken alles machen könnte - Pipifax. Ich habe ganz andere Prioritäten: die Microsoft-unabhägige Entwicklung etwa, mit einem Compilat das ohne Abhängigkeiten mit x anderen Komponenten serverseitig standalone läuft. Und irgendein Browser mit Javascript, das ist alles was clientseitig nötig sein darf. Mehr können die meisten Ziel-Kunden sowieso nicht handlen.

Deshalb fand ich dias REST Projekt in XE5 interessant, es braucht weder einen bestimmten Webserver noch .net Framework, keine Java Runtimes und keinen PERL Interpreter, und so weiter. JSON fand ich angenehm zu benützen, und es erlaubt mir ein wenig zwischen html und Daten zu differenzieren, was wiederum der Sicherheit gut tut, und mir viel herumgepfusche mit html und css erspart. RAD Studio auf dem Server und Firefox auf dem Client geben mir eine vollständige Debug-Umgebung. Serverseitig kann ich mit Delphi so ziemlichz alles machen was menschenmöglich ist. Lediglich die fehlende Dokumentation stellt dem System derzeit ein wenig ein Bein.

Die Hoffnung auf Doku war auch der einzige Grund, Fieldings Dokument überhaupt durchzulesen, aber ich wurde ehrlich gesagt seht enttäuscht, ich fand da wenig greifbaren Inhalt, und das Wenige was da war ließ sich in der Delphi Implementierung bisher nicht wiederfinden.

Ich finde aber, nach dem was ich bisher programmiert habe, dass die Grundlagen, wirklich gute Webapplikationen für eine Firma zu schreiben, sofern man nicht gerade die ganze Welt mit Datenversorgen muss, durchaus vorhanden wären. Ob sie dann REST oder ROST oder RISK konform sind ist mir völlig egal, aber ich habe eine bestimmte Vorstellung wie ich mir die Architektur wünsche, und dem kam die Delphi Implementierung schon ziemlich nahe.

Ich werde noch ein wenig Zeit versenken.

GLEICHGESINNTE GESUCHT!

[Sir Rufo]

Also wenn ich noch mal stören darf :stupid:

Du willst mit Delphi einen REST-Server bauen? Gibt es einen besonderen Grund dafür, warum?

Ich habe gerade selber ein aktuelles Projekt mit REST-Schnittstelle (Delphi-Anwendung als Client) allerdings habe ich den REST-Server auf PHP aufgebaut.

Als Framework darunter habe ich Luracast Restler genommen und das funktioniert (interessanterweise) ganz hervorragend. Schau dir mal die Live-Demos an. Vor allem mit dem enthaltenen REST-Explorer kann man sich fast schon die separate Dokumentation sparen, denn so schön bunt wie das ist ...

Also ich für meinen Teil wäre niemals auf die Idee gekommen den Server in Delphi zu programmieren.

[Nimral]

Hi Rufo,

störe so oft Du willst - allerdings sollten wir die Fragen, wegen denen ich den Thread eröffnet habe, nicht aus dem Augen verlieren. zu viele Threads enden in filosofisch hoch interessanten Debatten. Ich bin auf konkreten Code oder Links zu Dokus aus.

Zitat:

Zitat von Sir Rufo (Beitrag 1277163)

Also wenn ich noch mal stören darf :stupid:

Du willst mit Delphi einen REST-Server bauen? Gibt es einen besonderen Grund dafür, warum?

Ich brauche ihn aus meiner Sicht nicht zu bauen, er ist schon da. Das ist genau das was die REST Demos in Delphi XE5 sind. Ich möchte da nur noch einige Details anders haben, im großen und ganzen bin ich bereits mit dem was ich bis jetzt geschaffen habe hoch zufrieden.

Zitat:

Zitat von Sir Rufo (Beitrag 1277163)

Ich habe gerade selber ein aktuelles Projekt mit REST-Schnittstelle (Delphi-Anwendung als Client) allerdings habe ich den REST-Server auf PHP aufgebaut.

Mein Client ist - per Kundenanforderung - ausschließlich ein Browser mit Javascript.

Und REST habe ich mehr oder weniger untergejubelt bekommen, ich war eigentlich auf JSON aus. Im REST Datasnap Projekt steckt unter der Haube eine komplette JSON Implementierung, samt Indy basiertem standalone Webserver, die soweit ich das bisher erlebe ausgezeichnet funktionieren. Ich habe lediglich einige technische Details - siehe erstes Posting - wo ich nicht weiterkomme, und dachte, eventuell finde ich jemanden, der mir da Zeit spart, oder mit dem ich zusammenarbeiten kann. Es muss nicht jeder für sich das Rad nochmal erfinden.

Und ich gebe die Frage zurück ... angenommen jemand kann gleich gut PHP wie er Delphi (oder irgendeine andere klassische Programmiersprache samt IDE kann) - warum sollte er dann PHP wählen?

Und wenn er die Möglichkeit hat, einen für seine Zwecke weitaus besser geeigneten Webserver als die "Plattformen" IIS oder Apache per Delphi (Indy) zu bauen - und den Server sogar fixfertig gebaut vorgesetzt bekommt - warum sollte er das nicht tun? Warum sich mit der Komplexität moderner Webarchitekturen herumplagen, und sich von (Microsoft, Google, Apple, da sind alle Großen gleich) regelmäßig "Technologieen" aufzwingen lassen, deren Nutzen für den Anbieter man sofort sieht - wenn sie einem selbst keinen sichtbaren Nutzen bringen?

Zitat:

Zitat von Sir Rufo (Beitrag 1277163)

Also ich für meinen Teil wäre niemals auf die Idee gekommen den Server in Delphi zu programmieren.

Ich bin etwas verwundert, wieso Du das so kategorisch ausschließt, zumal das hier doch Delphipraxis.net ist ...

Gruss Armin.

[mkinzler]

Es gibt auch andere Lösungen für einen REST(ful) Server unter Delphi:
- Synopse mORMot
-Habari Web Component Server von mjustin
-TMS xData/TMS RemoteDB
...

[Nimral]

Hi Markus,

Zitat:

Zitat von mkinzler (Beitrag 1277173)

Es gibt auch andere Lösungen für einen REST(ful) Server unter Delphi:
- Synopse mORMot
-Habari Web Component Server von mjustin
-TMS xData/TMS RemoteDB
...

gut zu wissen - wenn ich die Flinte ins Korn werfen möchte, dass es Alternativen gäbe. Aber noch habe ich Hoffnung, dass ich das Ding in den Griff bekomme. Die Chancen stehen m.E. sehr gut. Ich werde auf jeden Fall eine gut funktionierende Lösung bekommen (aus Sicht der Anwender), die Frage ist, ob ich auch mit dem was "untern Blech" steckt zufrieden bin. Wenn ja, mache ich mein nächstes Projekt wieder so, wenn nein, suche ich nach einer Alternative.

Es hört sich immer gut an ... "nimm doch einfach das oder jenes, da hast Du dan VIEEEEEEEEL weniger Scherereien", aber ich mache schon viel zu lange Software um sowas unbesehen zu übernehmen, und bis man das "dies oder jene" im Griff hat braucht es idR Monate, wenn nicht länger. So lange möchte ich nicht warten, und der Kunde würde das wohl auch kaum bezahlen.

Gruss Armin.

[Phoenix]

:gruebel: Wenn Du so überzeugt von der Lösung auf Basis der REST-Demos bist, warum listest Du dann überhaupt deren Nachteile aus Deiner Sicht auf und fragst Du dann überhaupt ob sie der Weisheit letzter Schluss sind.

Du schriebst:

Zitat:

Zitat von Nimral (Beitrag 1277051)

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).

Meine Meinung dazu: Delphi war mit der VCL schon immer ein grandioses Tool für Desktop-basierte GUI Applikationen, und da ist es zuhause. Alles im Bereich Web (Intraweb etc.) war nicht wirklich durchdacht und hat nicht wirklich skaliert. Auch DataSnap bringt ziemlich viele Unzulänglichkeiten mit sich. Du stelltest ja selber die Tauglichkeit der REST-Implementierung in Frage. Von daher sind alternative Vorschläge von Rufo und unseren anderen Kollegen durchaus gefragt. Zumindest wenn man den Thread inhaltlich etwas verfolgt kann man Deine Aussage oben sehr leicht als grundsätzlichen Zweifel an der Delphi-REST Geschichte deuten.

Und dann schreibst Du noch das da:

Zitat:

Zitat von Nimral (Beitrag 1277051)

Ich habe ganz andere Prioritäten: die Microsoft-unabhägige Entwicklung etwa, mit einem Compilat das ohne Abhängigkeiten mit x anderen Komponenten serverseitig standalone läuft. Und irgendein Browser mit Javascript, das ist alles was clientseitig nötig sein darf. Mehr können die meisten Ziel-Kunden sowieso nicht handlen.

Ja, sorry. Aber wenn Du unabhängig von Microsoft sein willst, ist Delphis REST, das zwangsläufig auf Windows läuft, nicht das richtige. Da sind dann Hinweise auf PHP oder z.B. NodeJS vollkommen richtig platziert, da sie unabhängig von Microsoft (und seinem Windows) sind und wirklich überall laufen.

Aber nun gut. Nehmen wir mal an, das Du das Delphi-REST nicht in Frage gestellt wäre und eine 100%ige Mircosoft-Abhängigkeit für den Serverteil auch problemlos ist. Sagen wir also, der Server-Teil ist gesetzt. Du willst unbedingt Delphi machen, Hosting auf Windows ist kein Problem und mit den REST-Komponenten kommst Du klar und hast keine Zweifel. Du musst zwar vermutlich 4-5mal so viel Code schreiben wie mit anderen Lösungen die im Web-Umfeld wirklich zuhause sind, aber die Anwendung ist so klein, das sich ein Einarbeiten in andere Technologien hier ausnahmsweise mal wirklich nicht lohnt.

Dann steht immer noch folgendes aus dem OP im Raum:

Zitat:

Zitat von Nimral (Beitrag 1277051)

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 habe Dir zum Client (also dem Teil der Applikation, der im Webbrowser läuft), mit Angular (oder Ember, aber Angular ist weiter verbreitet, Du findest dort mehr Support und Doku etc.) eine sehr gute Alternative zu Divs ein- und ausschalten geliefert, du kannst mit Angular und dem Routing Module die Browser back-forward Dinge von Haus aus nutzen und durch die Modularisierung Deiner Anwendung in Angular hättest Du das Thema unübersichtlichkeit auch im Griff.

Ich habe Dir also mit dem Hinweis auf kostenlose, Open-Source Client-Seitige MVC bzw. SPA Frameworks genau die Fragen beantwortet, die Du gestellt hast:

Frage: Sind die Demos der Weisheit letzter Schluss?
Antwort: Nein. Sie sind nur Demos. Heutzutage schreibt man den Browser-Teil von Webapplikationen als entkoppelte, gut testbare MVC-Applikationen, die mit einem (in was auch immer gemachten) REST-Server kommunizieren. Das dabei bevorzugte Datenformat zur Übertragung ist JSON (oder JSONP), weil man hier Clientseitig die Daten einfach so nehmen und weiterverwenden kann.

Dennoch bist Du mit so einer Antwort *auch* nicht zufrieden gewesen.

Wir bemühen uns nach Kräften, auf Deine Fragen und geäußerten Zweifel einzugehen, und machen Dir Vorschläge. Aber Du stösst uns vor den Kopf im Stile von "Ist doch alles Geil was ich hier mache, warum soll ich was anderes machen?"

Daher meine erst gemeinte Gegenfrage: Was willst Du eigentlich konkret von uns?

Ist alles gut was Du machst? Dann Frag bitte auch nicht nach Alternativen, indem Du das was Du hast offen anzweifelst und in Frage stellst.
Oder Frage, aber dann stosse uns nicht vor den Kopf, wenn Du Antworten bekommst.

Danke.

[Nimral]

Lieber Phoenix,

ich hatte keinesfalls die Absicht, Dich oder andere Member hier, die mir in Erfahrung mit Webprogrammierung Lichtjahre voraus sind, einen Streit anzufangen. Jeder fängt irgendwann mit einem Thema an, und beginnt dort als Anfänger, überblickt die großen Zusammenhänge noch nicht, stellt kleinliche und dumm anmutende Fragen, insofern bitte ich um Welpenschutz.

Andererseits habe ich bisher nicht den Eindruck (entschuldige, aber das Recht auf eine eigene, abweichende Meinung ist normalerweise auch dann geduldet, wenn sie falsch ist), dass ich hier jemanden gefunden habe, der die Interna von REST Servern in Zusammenhang mit JSON und Delphi erkundet hat.

Die Hinweise auf Ember und Angular habe ich durchaus ernst genommen, immerhin sind sie JavaScript basiert und erfüllen damit eine meiner Rahmenanforderungen, und ich habe versucht, mich schnell zu orientieren. Fazit: es gibt noch ein Drittes Framework (Backbone.js), und vermutlich inzwischen noch einige mehr, und Amgular und Ember stehen im Ruf, dass man sie nicht mal so einfach im Vorbeigehen einschnupft, sondern sich massiv einarbeiten muss. Zu Backbone habe ich nicht lang recherchiert, da Du davon nichts gesagt hattest, es soll wohl etwas leicher zu verdauen sein. Aber das ist nicht der Knackpunkt. Wie stehen wohl meine Chancen, solche Schwergewichte mit dem weitgenend undokumentierten REST Framework von Delphi zu kombinieren?

Ich hatte zu Anfang drei ziemlich konkrete Fragen, und habe dafür aber keine konkreten Antworten bekommen. Statt dessen versucht jeder (wieder mein Eindruck) mich in die Ecke zu ziehen wo er sich auskennt. Vielleicht wäre es ja zu meinem Besten, aber das wird man erst hinterher wissen.

Und jetzt Du. Wenn Du magst. Und ich wollte Dich weder kritisieren, noch anzweifeln, noch runterputzen, noch ärgern, aber ich hatte, wie schon gesagt, einige konkrete Fragen, wäre mit einem "weiss ich auch nicht" oder "frag mal den da" zufrieden gewesen, es gibt vermutlich auch noch andere Communities wo sich Leute treffen die mit Delphi arbeiten, und ich werde statt dessen in eine Diskussion hineingezogen die nirgendwo hin führen wird, außer dass sich Leute ärgern über mich, obwohl das nie meine Absicht war.

Lasst mich bitte ins Verderben rennen, ich wollte es so.

Armin.

[Phoenix]

Hi Armin,

Zitat:

Zitat von Nimral (Beitrag 1277235)

ich habe versucht, mich schnell zu orientieren. Fazit: es gibt noch ein Drittes Framework (Backbone.js), und vermutlich inzwischen noch einige mehr, und Amgular und Ember stehen im Ruf, dass man sie nicht mal so einfach im Vorbeigehen einschnupft, sondern sich massiv einarbeiten muss.

So viele sind es auch wieder nicht nicht. Es gibt auch noch Knockout. Aber mal diese verbreitetsten im Vergleich:

https://www.google.de/trends/explore...2%2025m&cmpt=q

Der Punkt ist einfach, das Angular im Vergleich zu den anderen so viel populärer ist (die Tendenz erkennt man ziemlich deutlich in der Trend-Analyse), das man hier davon ausgehen kann, das es uns auf jeden Fall noch eine ganze Weile erhalten bleiben wird, und das man in der Community auch immer einen Ansprechpartner finden wird, der einem Weiterhelfen kann. Bei Ember, Backbone und Knockout sieht das anders aus. Knockout hat dazu den Nachteil, das da genau 2 Leute bei Microsoft dran arbeiten. Da ist nicht so der Drive dahinter, auch wenn es fast populärer ist als Ember und Backbone (was mich selber grad etwas überrascht hat).

Zitat:

Zitat von Nimral (Beitrag 1277235)

Zu Backbone habe ich nicht lang recherchiert, da Du davon nichts gesagt hattest, es soll wohl etwas leicher zu verdauen sein.

Ich würde sagen, egal mit welchem Framework Du anfängst: Die Einarbeitungszeit ist in etwa gleich. Ich gehe von 2-3 Wochen aus bis man das komplett durch geschnackelt hat. Aber nach der Zeit hat man zum einen schon was in der Hand, was man da gebaut hat und an dem man das gelernt hat, und man weiss wirklich wie es läuft. Danach ist man echt flott unterwegs damit.

In den ersten zwei Wochen wirst Du auf jeden Fall viel Code wieder wegwerfen, weil Du vieles rumprobierst. Es gibt bei Angular eine Goldene Regel, und wenn man sich an die hält, hat man hinten raus eher weniger Probleme: Niemals, wirklich niemals in einem Controller (oder noch schlimmer Service) auf den DOM zugreifen. Nie.
Wenn man das beherzigt, flutscht das irgendwann von alleine.

Zitat:

Zitat von Nimral (Beitrag 1277235)

Aber das ist nicht der Knackpunkt. Wie stehen wohl meine Chancen, solche Schwergewichte mit dem weitgenend undokumentierten REST Framework von Delphi zu kombinieren?

Ich würde sagen, nahe bei 100%.

REST ist doch im Prinzip ganz einfach: Man rufe beim Server eine URL auf, der Server antwortet, man verarbeitet die Antwort.

Auch wenn ich, wie gesagt, Delphi nicht unbedingt für das beste Tool auf einem (Web)Server halte, Du sagtest ja, Du bist hier schon ziemlich weit gekommen.

Beispiel:

Rest-URL: http://localhost:8080/restapi/getThing?id=1
Antwort vom Server: { "type": "ding", "id": 1, "someOtherProperty": "wrdlbrmpft" }

Zum Testen von REST-Schnittstellen empfehle ich übrigens das Plugin POSTMan in Google Chrome: https://chrome.google.com/webstore/d...pjoooidkmcomcm

Hiermit kannst Du sehr einfach beliebige Anfragen an Deinen Server stellen und die Antworten auch gleich überprüfen, ohne erst rumcoden, alles wegtracen und/oder debuggen zu müssen. Du siehst sofort, ob die Antwort dem entspricht was Du erwartest. Wenn nein, schickt der Server was falsches, falls doch, reagiert der Client vermutlich nicht korrekt.

Ob Du nun aber in Deiner Anwendung im Browser pper jQuery den REST-Call machst:

Code:

var type;

$.getJSON("http://localhost:8080/restapi/getThing?id=1",
   function(data) {
      type = data.type;
   }
);

Oder ganz ohne JavaScript Bibliothek oder Framework, 'von Hand', sozusagen:

Code:

var type,
  xmlHttp = new XMLHttpRequest();

if (xmlHttp) {
    xmlHttp.open('GET', 'http://localhost:8080/restapi/getThing?id=1', true);
    xmlHttp.onreadystatechange = function () {
        if (xmlHttp.readyState == 4) {
            var data = JSON.parse(xmlhttp.responseText);
            type = data.type;
        }
    };
    xmlHttp.send(null);
}

oder ob Du den Call mit Angular machst in einem Deiner Controller machst:

Code:

function myController($scope, $http) {
   var type;
    $http.get('http://localhost:8080/restapi/getThing?id=1').
        success(function(data) {
           type = data.type; 
           $scope.type = type;
        });
}

In allen drei Fällen hast Du am Ende 'Ding' im type stehen.
In den ersten zwei Fällen müsstest Du Dich jetzt noch drum kümmern, dass die Info auch irgendwo noch dargestellt wird (= Position im DOM ermitteln, und den Wert da reinschreiben).

Im Angular-Beispiel packe ich den Wert der variablen type noch auf den scope, (okay, die variable wäre unnötig, aber ich will die samples analog halten).

habe ich dann dort zum Beispiel dieses Html:

Code:

<div ng-controller="myController">
   <p>The Thing is a  {{type}}</p>
</div>

Wird der Platzhaler {{type}} automatisch durch den richtigen Wert ersetzt. Und sollte sich der Wert auf dem Scope irgendwann ändern, dann wird die Änderung komplett automatisch auch in der View nachgezogen (data binding).
Das ganze geht freilich in beide richtungen, also wenn Du den Wert an eine Input-Box bindest, dann kannst Du auch direkt im Model live auf Änderungen reagieren.

Ein kleines Beispiel, das sogar komplett ohne Code auskommt: http://jsbin.com/padoyizeke/edit?html,output

Der Gag dabei ist, das die gebundenden Werte sofort im sogenannten Model zur Verfügung stehen.
Und damit schliesst sich dann der Kreis: Du bindest Werte an Ein- und Ausgabelemente, und Aktionen (Methoden) an Steuerelemente (z.B. einen Button). Hier kannst Du einfach auf Dein Model-Objekt zugreifen und hast sofort alle Eingaben in der Webanwendungen zur Hand, und kannst die dann ganz einfach an den Server schicken, die Antwort annehmen und sofort wieder binden.

Am Ende des Tages kümmerst Du Dich um den ganzen Quatsch wie HTTP, JSON, REST gar nicht mehr. Das tut einfach.