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

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

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]

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.