Restful Frontend-Architecture

05/16/12
RESTful Web-UI Architecture
Sandro Sonntag, Technical Lead
adorsys GmbH & Co. KG

05/16/12 Cloud Centric Thin-Server-Architecture / Sandro Sonntag - adorsys GmbH & Co KG
Die Probleme von herkömmlichen
Thin-Client-Architekturen
2

Daten und Repräsentation
sind vermischt
Browser Server
Name Foo
Nachname Bar
Str Laufer-Str 99
➡Datenstrukturen?
➡Datentypen?
<html>
<body>
<span>Name: Foo</
span>
➡Daten und
Repäsentation
gemischt
➡Präsentationsflow und
Datenaustausch gemischt
3

Resourcen am Client werden nicht genutzt
Rich-Server
berechnet das
GUI
für jeden
Client
Client
Client
Client
4

Usability erfordert eine flüssige Bedienung.
Hohe Latenz
Seite 1 Seite 2 Seite 3 Seite 4
Browser
GET POST POST POST
➡Herkömmliche Webapps reagieren zu langsam auf
Benutzer-Interaktionen.
5

Komplexität
Präsentationslogik ist am Client und
Server
Webframework ein Codegenerator
für HTML & JS(denken in 2
Dimensionen - sehr umständlich)
HTML muss erst in Server Templates
verpackt werden
Debugging in zwei
Laufzeitumgebungen (Client/
Server)
Der meiste Code dreht sich um das
Event/Request Handling
(Serialisierung, Protokoll quirx)
Korrektes State Handling unmöglich
Client Code
(HTML, JS, CSS)
Webframework
Generate
GUIEvents
State
6
State

UI-State am Server
Problem: Statemanagement
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
Client muss immer auf den richtigen Server geroutet werden
Skalierung und Failover ein echtes Problem (und sehr teuer)
Speicherverbrauch am Server (Beispiel JSF Component Tree)
Server behelfen sich mit Sessiontimeouts (Session bleibt meist noch 30 Minuten
wenn der User bereits weg ist)
7

05/16/12
Offlinefähigkeit
Nicht möglich

Fehlende Interoperabilität
HTML Markup ist keine Schnittstelle
Echte Services sind häufig nicht von „außen“ zugreifbar (z.B. Spring Services)
• ... nein, man kann Sie nicht einfach zum Webservice machen!
◦ es ist ein fundamentaler Unterschied ob ein Service als WebService oder lokaler Service
konzeptioniert wurde (Fehlerbehandlung, Call by Value, Granularität)
• Ergo: Webservice Projekte müssen von 0 starten
◦ Risiko das Rad neu zu erfinden
Fehlender Fokus auf qualitative Schnittstellen („die sind ja nicht von außen
erreichbar“)
Präsentation und Geschäftslogik in einem Tier fördert das vermischen zu
einem „Brei“
9

Symptome linderbar, aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
Browserhistory -> Post/Redirect/Get (PRG)
Browsernavigation -> bsw. durch JSF-State-Saving und Memory limitiert
Failover -> Session Replication ist nicht praktikabel! (Speicher, Kosten, Network
Traffic..)
Verhindert echtes Webscale!
10

05/16/12
Ausweg:
Thin-Server-Architekturen

3 Tier - so wie es sein soll
Business Logic
HTML Renderer
Controller View
Model
Server
Client
Präsentation
Controller View
Model API
Business Logic
Server
Client
12

DOM
und so in JavaScript:
Event Listener Function
1. addEventListener
2. getElementById
/backend
3. jQuery.ajax
13

Zur Erinnerung: Der JSF Lifecycle
14

Die Möglichkeiten des Browsers den Zustand zu speichern...
Stateless Server aber wohin mit dem State?
JS var
Cookie
local/session Storage
BrowserDB
HTML5 History API
URL Hash (#)
15

Semantic HTML 5
Don’t hide the Web
HTML als Inhalts-Beschreibungssprache
CSS für das Layout
CSS/ Javascript Features variieren zwischen den Browsertypen
Aber: Oberfläche sollte in den immer funktional bedienbar sein
“Progressive-Enhancement” für “Aufhübschung” von Oberflächen ohne
funktionalen Einfluss
Gutes HTML hat einen hohen Wert!
• Responsive Webdesign
• Suchmaschienen
• Geringer Datentransfer
• Leichte Anpassbarkeit des Layouts
Eine gute HTML Struktur ist vergleichbar mit OOD und erfordert Erfahrung
• Floting boxes, CSS Classes/ID, DIV, Browserkompatibilität etc
Mit HTML Frameworks wie Bootstrap kann man die gröbsten Fehler vermeiden
16

05/16/12
HTML(5) hat alles was man braucht
JavaScript für die Oberfächensteuerung
DOM Selector API um die View zu manipulieren
AJAX für den Zugriff auf Geschäftslogik

05/16/12
No Serverside Webframeworks
HTML5 ist das Framework!

05/16/12
Von JavaScript und HTML zu
einer wartbaren Frontend-Architektur

Auch einfache Anwendungen erfordern eine
Architektur
20

für einfache Anwendungen
Rich Internet Application (RIA) Architecture
View (HTML)
Controller (JS)
Service / Resource
Network
‣ Ein großes Javascript...
‣ Eine HTML-Seite bestehend aus “Unter-Seiten”
‣Nicht geeignet für komplexe Anwendungen
21

erfordern Komponentisierung
RIA’s
22

Model View Presenter (MVP) vs. MVC Pattern
View
Presenter
Model
ModelView
Controller
23
prostuliert durch Google
First Class Pattern in GWT
Vorteil: Bessere Trennung von UI und Controller-Logik
• Dadurch:
• Bessere Austauschbarkeit von Model,View und Controller
• Bessere Testbarkeit

erfordert ein Bus System
Kommunikation in Rich Internet Applications
24

Network
Mail ChatMenü
Lose Kopplung von UI-Komponenten
durch Pub/Sub
View
Presenter
Event Bus
View
Presenter
View
Presenter
Application
Controller
Service
25

hierdurch ist Wiederverwendung von Fachlichen UI-Komponenten möglich
Komponentisierte Frontend-Architektur
26
KomponenteKomponente
Widget
Application Controller
Dialog
Event Bus
Sitzung
Öffentlicher Service
Dialog
View
Event
(sende Richtung)
Dependency
(Abhängkeit zu)
Legende
Dialog
Komponenten Controller
Öffentlicher Service
Optionaler
Baustein
Dialog
Presenter
View

Gängige Webservice-Protokolle
Grundsätzlich HTTP basiert
RESTful HTTP
• JSON
• XML
• Feeds - ATOM/RSS
• RDF
SOAP / WS-*
Push Technologien
• Comet/Ajax Push
• Websocket
27

und JSON auf dem Vormarsch
RESTful HTTP ist führend
28

REST Principals
Give every “thing” an ID
Link things together
Use standard methods
Resources with multiple representations
Communicate statelessly
29

Warum REST?
Skalierung
Fehlertoleranz
Wiederherstellbarkeit
Sicherheit
Lose Kopplung
30

für lose Kopplung von Severices
Hypermedia
Inspiriert von Hypertext. Paradigma: folge den Links
Schlagwort: HATEOAS (Hypertext As The Enging Of Application State)
• Resourcen sind selbst beschreibend
• Gibt Auskunft über State und Verhalten
Ziel: Applikationen sollten kein Wissen über die semantic von URLs haben
(starke Kopplung)
31

Beispiel einer Hypermedia HTTP Response
32
<articles total="1921" xmlns:atom="http://www.w3.org/2005/Atom">
<atom:link rel="self" href="http://www.example.org/articles?contains=cycling&start=10"/>
<atom:link rel="prev" href="http://www.example.org/books?contains=cycling"/>
<atom:link rel="next" href="http://www.example.org/books?contains=cycling&start=20"/>
<article>
<atom:link rel="self" href="http://www.nytimes.com/2009/07/15/sports/cycling/15tour.html"/>
<title>For Italian, Yellow Jersey Is Fun While It Lasts</title>
<body>...</body>
</article>
<article>
<atom:link rel="alternate" href="http://www.nytimes.com/2009/07/27/sports/cycling/27tour.html"/>
<title>Contador Wins, but Armstrong Has Other Victory</title>
<body>...</body>
</article>
</articles>

GUI Rendering am Client
Konzept: Stateless Backend
• REST
• Caching (Client/Server)
• einfache und „billige“ Skalierung
• durch zusätzliche Hardware
• keine (sticky) Sessions
◦ transparent Failover
Scaling RESTful Architectures
Server Server
Client Client
33

Authentication in RESTful Apps
Gängige Authentisierung in Severside-Webapps basiert auf HttpSession Auth
• Aber: nicht Restful (HTTPSession)
Restful Authentisierung erfordert Zustandslosigkeit (Server seitig)
Restful Technologien:
• Simple per HTTP Basic/Digest Auth
• Client Cert Auth
• Security Tokens
◦ Eigene Protokolle
◦ OAuth
◦ OpenID
34

RESTful Authentication mit OAuth
Service
Provider
Service
Client 4. erzeuge Access Token
2.AuthentisiererequestToken
Token
Server
(IdP)
1. erzeuge Request Token
5. API Call
3. redirect request Token
param
6.checkToken
35

Zusammenfassung
Der REST
Die klassischen Frameworks wie JSF/Stuts kommen aus einer Zeit (2000-2004) in
der AJAX und JavaScript noch keine grosse Rolle gespielt haben
Heutige Anforderungen an User Experience lassen sich mit klassischen
Technologien nur unter Schmerzen umsetzen
Server-Side-Frameworks können mit den Anforderungen umgehen, sind
jedoch keinenfalls dafür entwickelt worden
Die Komplexität von aufgerüsteten Server-Side-Anwendungen steigt eminent
durch den Mix von JavaScript und AJAX
Die Architektur des Webs (RESTful) wird bei vielen Server-Side-Anwendungen
gebrochen mit Auswirkungen auf Robustheit, Skallierung und User
Experience
36

Restful Frontend-Architecture

Weitere ähnliche Inhalte

Was ist angesagt?

Ähnlich wie Restful Frontend-Architecture

Restful Frontend-Architecture