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

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

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

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

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 von Sir Rufo:

Also wenn ich noch mal stören darf

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 von Sir Rufo:

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 von Sir Rufo:

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