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

[Nimral]

Hi Markus,

Zitat von 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
...

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]

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 von Nimral:

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 von Nimral:

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 von Nimral:

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 von Nimral:

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 von Nimral:

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 von Nimral:

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.