Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

REST – ein Erfahrungsbericht

Ähnliche Präsentationen


Präsentation zum Thema: "REST – ein Erfahrungsbericht"—  Präsentation transkript:

1 REST – ein Erfahrungsbericht
Mathias Pannier Alt. Titel: Stolpersteine auf dem Weg vom klassischen Client/Server Entwickler zum "modernen" REST Server Entwickler – ein Erfahrungsbericht es geht nicht um ein vorgehen nach Lehrbuch es geht nicht um Quellcode bzw. konkrete Implementierungen es geht vielmehr um meine persönlichen Erfahrungen bzw. Fragestellungen die in diversen Projekten zu diesem Thema aufgetaucht sind und in den Hallo Welt Beispielen nicht gezeigt werden ich habe 10 – 15 Jahre lang C/S Anwendungen entwickelt. D.h. viele Probleme die ich hatte haben mit dieser Umstellung/Vorgeschichte zu tun.

2 Agenda Was ist REST? Transaktionen Security Performance (Mehr) Aufwand
Rest Client in 5 Minuten Ich habe mir folgende Punkte für heute rausgesucht. Es gibt aber noch deutlich mehr bzw. ist die Liste bei weitem nicht vollständig. Auch die angesprochenen Themen sind nicht zu 100% behandelt. Schön wäre es zu jedem Thema auch eure Meinung zu hören. mathiaspannier.wordpress.com

3 Über mich Name: Mathias Pannier
Position: Softwareentwickler/Teamleiter Mehr als 15 Jahre Erfahrung mit Softwareentwicklung in Delphi Blog: mathiaspannier.wordpress.com mathiaspannier.wordpress.com

4 Fragen Wer kann mit dem Thema REST/WebService gar nichts anfangen?
Wer hat bereits einen REST Server / WebService erstellt? Wer hat bereits einen REST Client erstellt bzw. einen WebService benutzt? Wer hat eine Anwendung mit COM/OLE Automatisierung erstellt bzw. ein eigenes SDK für andere Entwickler zur Verfügung gestellt? Wer hat bereits eine mehrschichtige Anwendung gebaut? (MIDAS, CORBA) Zu den letzten beiden Fragen: Die Probleme sind ähnlich. mathiaspannier.wordpress.com

5 Was ist REST? Representational state transfer (REST) oder RESTful Web services (https://en.wikipedia.org/wiki/Representational_state_transfer) Client-Server Stateless Cacheable Layered system Uniform interface Als kurze Zusammenfassung/Übersicht für alle die damit nicht vertraut sind. Offizielle „Definition“ kann jeder nachlesen. Ich möchte es gern mit meinen eigenen Worten erklären mathiaspannier.wordpress.com

6 Was ist REST? Meine eigene Erklärung jenseits von wikipedia:
ist ein quasi "Standard" für die Entwicklung von verteilten Anwendungen Basis ist das HTTP Protokoll mit den Verben (GET, POST, PUT usw.) alles ist eine URL (Ressource) es geht darum Daten (z.B. aus einer Datenbank) über eine einheitliche (Web) - Schnittstelle zur Verfügung zu stellen erleichtert die Erstellung unterschiedlicher Clients (Mobil, Win32/64, HTML/JS) in dem Bereich fällt oft der Begriff JSON wird meist als leichtgewichtiges Austauschformat gegenüber XML genutzt es kann aber auch XML oder Plain Text verwendet werden ist nicht festgelegt einfache Verwendung in einem HTML/JavaScript Client Für den weiteren Verlauf ist wichtig zu wissen: Man ruft über HTTP eine URL auf und erhält Daten in Form von JSON zurück. mathiaspannier.wordpress.com

7 Transaktionen ein größeres Problem bei der Umstellung von C/S zu REST sind Transaktionen man ist es gewöhnt an einer Stelle (im Client) eine Transaktion zu starten und beliebig viele SQL Abfragen auszuführen (insert, edit, delete, select) Transaktionen im Client starten ist nicht mehr möglich es gibt einen Aufruf einer Ressource URL (lesend oder schreibend) (HTTP) delete from Tabelle1 (HTTP) delete from Tabelle2 -> sind 2 Aufrufe in 2 DB Transaktionen (HTTP) delete from Tabelle1 and Tabelle2 -> ist ein Aufruf in einer Transaktion Wer von C/S zu REST umstellt muss etwas umdenken was Transaktionen betrifft Im Bereich noSQL Datenbanken gibt es zum Teil gar keine Transaktionen mehr; man spricht da von BASE im vergleich RDBMS ACID. - Basically Available - Soft-state - Eventual consistency mathiaspannier.wordpress.com

8 Transaktionen um Daten z.B. aus mehreren Tabellen innerhalb einer Transaktion abzufragen (select) gibt es dennoch nur einen (HTTP) Aufruf zum (REST) Server innerhalb des Servers können wie gewohnt mehrere SQLs in einer Transaktion abgesetzt werden zu beachten ist: alle benötigten Daten müssen mit einem Aufruf zum Server gesendet werden Auf keinen Fall mit einem (HTTP) Aufruf eine Transaktion starten, dann mit weiteren Aufrufen Daten lesen/schreiben und mit einem finalen Aufruf die Transaktion beenden. Transaktionssteuerung wird zum Server verlagert Problem der langanhaltenden Transaktionen und ggf. nicht beendeter Transaktionen Außerdem mehrere gleichzeitige Besucher (richtige Transaktion zum richtigen Client muss gesucht werden) Man hat wieder einen Status mathiaspannier.wordpress.com

9 Security Entscheidung zwischen Public vs. Private REST Server
Zugriff von externen Entwicklern möglich/gewünscht Private: LAN intern ohne Zugriff von außen (außer VPN) Zugriff nur durch eigene Programme das Thema Eingabevalidierung erhält einen viel höheren Stellenwert als in einer klassischen C/S Anwendung es reicht nicht z.B. in einem HTML Formular das „Required“ Feld zu setzen oder das Feld als Adresse zu definieren alles MUSS serverseitig validiert werden; Client Validierung „nur“ um Usability zu verbessern Security - Abseits von Authentifizierungs- und Autorisierungsverfahren wenn etwas öffentlich über eine IP/URL erreichbar ist wird es angegriffen In C/S Anwendungen oft nur Formularvalidierung + DB Validierung (Tabellenstruktur, Datentyp, Not Null Felder) bzw. werden Daten nur über die eigene Anwendung zum Server übertragen und „die macht es schon richtig.“ Servervalidierung im Public Umfeld: Daten können unabhängig von einer (eigenen) GUI autom. zum Server gesendet werden Schutz vor Datenmüll / Richtigkeit der Daten pro Feld z.B. über Regex Masseneinfügungen Das richtige Format (JSON – Dokument) muss geprüft werden Logische Prüfung der Daten mathiaspannier.wordpress.com

10 Security ein GET verrät mehr als ich eigentlich sagen wollte
Wenn Bsp. in einer Anwendung Daten aus einer DB abgefragt werden und je nach Benutzeranmeldung unterschiedliche Felder nicht sichtbar sein sollen, dann dürfen Sie auch nicht mit ausgeliefert werden! JSON Daten sind "sichtbar" auch wenn Sie nicht in der Oberfläche angezeigt werden Fehlermeldungen verstecken bzw. „umformulieren“ eine Datenbank Exception sollte nicht bis zum Benutzer durchdringen kann von einem Angreifer ausgenutzt werden interne Datenstruktur sichtbar Fehlermeldung als HTTP Statuscodes mit Zusatzinformationen Fehlermeldungen verstecken -> immer aus Sicht einer öffentlichen Schnittstelle mathiaspannier.wordpress.com

11 Performance Sind REST Server (wenn Sie gut implementiert sind) performanter im Vergleich zu klassischen C/S Anwendungen? Ja (im WAN) und Nein (im LAN) SQL Server und deren Zugriffe über TCP/IP sind für LAN Verbindungen ausgelegt REST Aufrufe haben mehr Zwischenschritte zwischen der DB und dem aufrufenden Client (Serialisierung; ähnlich RPC/COM Aufrufen) Vorausgesetzt sie sind gut implementiert Ja/Nein ist meine Meinung und meine Erfahrung; Im WAN hat man direkt über z.B. Firebird SQL gar keine Chance. Es sind einfach mehr Komponenten beteiligt (Client, Webserver, Datenbank usw.) mathiaspannier.wordpress.com

12 Performance das Holen der Daten (wieviel und welche) muss wohl überlegt sein Balance zwischen der Anzahl der Aufrufe und der zurückgelieferten Datenmenge jeder Aufruf kostet Zeit bzw. hat einen Overhead bei HTML JS Clients oder in Multithreaded Anwendungen können mehrere parallele Aufrufe Vorteile bringen  WICHTIG: Connection Pooling verwenden in einem Aufruf sollten Daten aus mehreren Abfragen aggregiert werden (Master - Detail) man muss seine Anwendungsszenarien vorher gut definieren (am besten GUI Dummy erstellen) Man könnte wie gewohnt jede Tabelle in einem Aufruf sep. Abfragen. Zum Teil viele Aufrufe mit entsprechendem Overhead. ACHTUNG: Serverseitig muss alles Threadsafe sein! Wieviel und Welche: Welche Datenbankfelder brauch ich für meinen View bzw. für die Verarbeitung? Jedes Zeichen muss zum Client übertragen werden. Netzwerk – Reiter in Chrome Ein weiterer Punkt ist die Aufteilung der Get‘s nach Daten die man sofort benötigt und Daten die man im Hintergrund nachladen kann mathiaspannier.wordpress.com

13 Performance Cache alle großen Webseiten die "schnell" sind "leben" von gecachten Daten signifikante Performanceverbesserung aber viele "Probleme" (Aktualisierungen) Browser Cache nutzen (bei HTML/JS Clients) eigener Client Cache bei Win Anwendung serverseitiger Cache (Hauptspeicher oder „Memory“ Datenbanken) Interessantes Video Marco Cecconi - "The Architecture of StackOverflow" https://www.youtube.com/watch?v=t6kM2EM6so4 Faustregel: So wenig wie möglich Daten mit so wenig wie möglich Aufrufen. Cache muss Threadfest sein (Serverseitig); Viel RAM benötigt; Speicher DB Server (Redis) Alles was man Cacht „altert“ Wie finde ich heraus was für mich funktioniert: Teste, Testen, Testen Überwachen, Überwachen, Überwachen ist ein eigenes sehr komplexes Thema mathiaspannier.wordpress.com

14 (Mehr) Aufwand obwohl von den Marketingstrategen anders behauptet steigt der Aufwand je nach Programmiersprache/-umgebung gibt es bessere oder schlechtere Unterstützung (Tools für die Erstellung) man hat (zumindest in der Delphi Welt) min. eine zusätzliche Anwendungsschicht man muss sich zwangsweise mit dem Thema Webserver (IIS, Apache) auseinandersetzen einfaches CRUD auf Tabellenebene mit höherem Aufwand administrativer Aufwand steigt (vorher ein DB Server und ein Client; jetzt 1 DB Server, 1 App Server und mehrere unterschiedliche Clients) Versionierung der Schnittstelle muss beachtet werden (keine Typsicherheit beim Compilieren) Tools/Programmiersprachen – außerhalb von Delphi; Wer schonmal in JavaScript oder PHP ohne Compiler/Debugger entwickelt hat kennt die Probleme. Self Hosting Exe ist auch möglich Monitoring aufwändiger Updates fahren schwieriger (man muss mehrere Clients erreichen + eine Webseite ist rund um die Uhr erreichbar) mathiaspannier.wordpress.com

15 Fragen? mathiaspannier.wordpress.com

16 Rest Client in 5 Minuten https://www.youtube.com/watch?v=A0epsUp2Xfc
Zum Schluss vielleicht doch noch etwas Quellcode. Im Video bei ca. 32/33 Min. wird gezeigt wie man mit Delphi und dem REST Debugger einen REST Client in 5 Minuten baut. Das fand ich doch sehr beeindruckend. (Auch wenn es nur ein typisches einfachst Beispiel ist. Aber für den Anfang. https://www.youtube.com/watch?v=A0epsUp2Xfc mathiaspannier.wordpress.com


Herunterladen ppt "REST – ein Erfahrungsbericht"

Ähnliche Präsentationen


Google-Anzeigen