Vier Fragen, die Sie sich bei jedem Webprojekt stellen sollten

Silvia Schreier

Silvia Schreier

Eine Bestandsaufnahme zum Thema REST gibt Silvia Schreier (innoQ) auf der kommenden W-JAX (2. bis 6.11. in München). Auf JAXenter gibt sie einen kleinen Vorgeschmack auf ihre Session REST 2015 und zeigt, welche typischen Herausforderungen einem bei der Entwicklung eines zeitgemäßen Webprojektes begegnen.

In vielen IT-Abteilungen findet man inzwischen Webprojekte aller Art. Da in diesem Bereich sehr viel passiert, ist es kaum möglich, immer auf dem aktuellsten Stand zu bleiben, sodass man sich leicht von neuen Technologien verführen lässt. Hinzu kommt, dass es immer wieder Teams gibt, die ihr erstes Webprojekt durchführen und damit vor einer riesigen Bandbreite an Optionen und Herausforderungen stehen.

Ich habe immer wieder erlebt, dass die folgenden Fragen leider gar nicht oder zu spät gestellt werden. Ich hoffe, dass diese Sie zum Nachdenken anregen und Ihnen dabei helfen, Ihr Projekt erfolgreich durchzuführen.

Wie sichere ich meine Anwendung ab?

Eigentlich sollte man meinen, dass es bei einer Anwendung, die im Internet (oder auch Intranet) steht, selbstverständlich ist, dass diese abgesichert werden muss. Dabei geht es hier nicht nur darum, die Infrastruktur mit Firewalls zu schützen, HTTPS und Authentifizierung zu verwenden oder Sicherheitspatches für die verwendete Software regelmäßig einzuspielen. Wichtiger ist es, dem Client niemals zu vertrauen.

So ist es kein Argument, den Zugriff auf Ressourcen nicht zu schützen, weil der Client die URL nicht kennt, oder Daten nicht zu validieren, weil die ja aus dem Formular oder JavaScript kommen, welches der Server ausgeliefert hat. Die oberste Regel ist: Alles, was vom Client kommt, ist potenziell bösartig.

Für viele Angriffe gibt es bewährte Lösungen. So findet sich zum Beispiel beim OWASP eine hervorragende Security-Checkliste für Webprojekte [1]. Viele Frameworks bieten zudem Unterstützung für Validierung oder die in der OWASP-Checkliste aufgeführten Techniken, wie zum Beispiel Verfahren zur Verhinderung von Cross-Site-Request-Forgery (CSRF) [2].

Je nach Art der Anwendung ist oft auch PCI-Compliance [3] notwendig. Außerdem kann auch über Penetrationstests nachgedacht werden.

Was sind die Aufgaben der drei Säulen des Web-UIs?

Je nach Rolle im Projekt werden Sie mehr oder weniger stark mit HTML, CSS und JavaScript in Berührung kommen. Hier gilt es, die Grundlagen zu verstehen und wartbaren Code produzieren zu können. Oft wird die Komplexität dieser Sprachen unterschätzt und man meint, „das bisschen UI“ mal eben nebenbei machen zu können. Dabei hat jede der drei Sprachen ihre eigenen Aufgaben und für diese viele Features zu bieten, die auch voll ausgeschöpft werden sollten. Das heißt zum Beispiel, man sollte Dinge, für die HTML oder CSS verantwortlich sind, nicht mit JavaScript nachbauen, nur weil es eben geht. Die Trennung von Struktur, Aussehen und Verhalten hilft enorm, die Wartbarkeit zu verbessern.

Deshalb ist es auch korrekt, von einer Frontendarchitektur zu sprechen, die ein integraler Bestandteil der Gesamtarchitektur sein sollte. Selbst wenn man primär im Backend entwickelt, sollte man genauso ein Verständnis vom Frontend und dessen Interaktion mit dem Server haben, wie man eben auch eine Vorstellung vom Datenbankdesign hat.

Natürlich haben CSS und JavaScript auch ihre Tücken, aber diese kommen oftmals daher, dass der Code auf den verschiedensten Geräten und Browserversionen laufen muss und nicht nur auf einer wohldefinierten Serverumgebung. Umso wichtiger ist hier die entsprechende Testabdeckung und vor allem -automatisierung. Dank Frameworks wie Selenium ist dies ohne weiteres möglich. Unit- und Integrationstests für den Server sind schön und gut, doch wenn die Benutzer mit einem nicht funktionierenden UI konfrontiert sind, bringt es ihnen reichlich wenig, dass es ja auf dem Server funktioniert. Somit sollte auch für Unit- und Integrationstests für das UI entsprechender Aufwand eingeplant werden.

Kann man moderne Web-UIs nur mit Single-Page-Application-Frameworks bauen?

Geht es heute darum, eine neue Webanwendung zu bauen, so muss natürlich alles schick und modern aussehen. Eine der Anforderungen, die ich immer wieder höre, ist: „Es darf keine Full-Page-Reloads geben“. Außerdem werden oft diverse andere Nettigkeiten wie Formularvalidierung beim Tippen oder Autocompletion gefordert.

Durch Artikel und Vorträge in den letzten Jahren ist bei vielen der Eindruck entstanden, dass all dies nur mit Single-Page-Applications (kurz: SPA) zu erreichen ist, die man dann mit einer schicken REST-konformen API verbindet. Die Vor- und Nachteile solcher Frameworks für den eigenen Anwendungsfall werden dabei oft gar nicht mehr evaluiert, da man ausnahmsweise mal „was Modernes“ machen will. Außerdem wird dann gerne behauptet, dass ja so jemand wie Google hinter Angular steht, es tolle Konventionen und Dokumentation gibt und noch dazu jede Menge Plug-ins für alles Mögliche, so dass jeder diese Framworks leicht lernen kann (unabhängig davon, ob man sich schon mal mit Webfrontends und JavaScript beschäftigt hat).

Über Wartbarkeit über einen längeren Zeitraum wird dabei ebenso wenig nachgedacht, wie die Verwendung auf mobilen Clients mit schlechter Verbindung sowie deren Akkuleistung. Hinzu kommt, dass man es auch dann mindestens mit zwei Anwendungen zu tun hat.

Natürlich gibt es Fälle, in denen eine Single-Page-Anwendung die richtige Wahl ist, und selbstverständlich kann man mit entsprechender Erfahrung auch gute Software damit entwickeln. Aber es ist eben auch nicht der heilige Gral der Webentwicklung, als der er häufig verkauft wird.

Besinnt man sich hingegen auf die drei Säulen des Web-UIs und deren Aufgaben und kombiniert das mit der Idee des Progressive Enhancements [4] und REST, so kommt man zu dem Schluss, dass es auch andere Mittel und Wege gibt, eine Anwendung mit dem gleichen oder vielleicht sogar besseren Erlebnis für den Benutzer zu entwickeln. Basierend auf diesem Ansatz ist ROCA (Resource-oriented Client Architecture) [5] entstanden. Dabei handelt es sich nicht um eine Technologie, sondern um einen Architekturstil für Webanwendungen, der es in meinen Augen ermöglicht, moderne, wohlstrukturierte und vor allem wartbare Software zu entwickeln. Dieser Ansatz ist genauso wenig der heilige Gral, und man muss ihn verstehen, um damit gute Software zu bauen. Aber hat man das erstmal getan, ist es ein sehr mächtiger Ansatz. Ein großer Vorteil ist in meinen Augen, dass die Verantwortlichkeiten sehr klar getrennt sind und es keine Duplikationen von Logik gibt, wie es bei einer REST-API und einer zugehörigen SPA häufig der Fall ist (bzw. sein sollte).

Ist ein API wirklich etwas völlig anderes als eine Webanwendung?

Gerade in Kombination mit dem SPA-Ansatz ist der Irrglaube entstanden, dass man erst ein API entwirft, das die ganze Geschäftslogik enthält, und anschließend ein zweites Frontendprojekt umsetzt. Betrachtet man nun aber REST genauer, wird man schnell feststellen, dass es – wie der Name schon sagt – darum geht, Repräsentationen auszutauschen. Dabei können diese natürlich für eine andere Anwendung gedacht sein, wie man es bei einem API in der Regel annimmt. Es spricht aber auch gar nichts dagegen – es ist sogar der ursprünglichere Anwendungsfall – für Menschen nutzbare Repräsentationen auszuliefern, in der Regel HTML. „Aber eine Repräsentation für eine Anwendung ist doch etwas völlig anderes als eine HTML-Seite“, kommt dann oft als Argument. Betrachtet man aber später die Anwendung genauer – ich habe das inzwischen mehrfach erlebt – stellt sich heraus, dass die inhaltlichen Unterschiede in den meisten Fällen gar nicht so groß sind und die benötigte Geschäftslogik oft identisch ist.

Noch dazu bietet HTTP Content Negotiation, d.h. der Server kann mehrere Repräsentationen in verschiedenen Formaten für eine Ressource anbieten, der Client kann mit Hilfe des Accept-Headers im Request dem Server mitteilen, welche Repräsentationen er versteht bzw. bevorzugt, und der Server kann dann im Rahmen seiner Möglichkeiten antworten. Allerdings sollte man sich bewusst sein, dass leider nicht alle Webframeworks gleich gute Unterstützung hierfür anbieten.

Wenn es einzelne Ressourcen gibt, die nur einer der Clients benötigt oder bei denen sich die Inhalte zu stark unterscheiden, kann man zusätzliche Ressourcen schaffen, die dann nur eine der Repräsentationen bereitstellen. Der Vorteil dabei ist, dass keine unnötige Doppelung von Code und Logik anfällt. Ein eigenes Frontendprojekt hingegen führt oft zu einer Menge Boilerplate-Code.

Fazit

Wenn Sie sich diese Fragen möglichst frühzeitig und gegebenenfalls auch im Projektverlauf nochmals stellen, dann haben Sie den richtigen Weg zu einem erfolgreichen Webprojekt eingeschlagen. Dabei sollte klar sein, dass es selten eine für alle Projekte gültige Antwort gibt.

Wer mehr zu diesen Themen erfahren will, kann entweder zu meinem Vortrag „REST 2015“ auf der W-JAX kommen [6], in der 3. Auflage von „REST und HTTP“ [7] nachlesen oder auch in den innoQ-Podcast zu diesem Buch reinhören [8].

Verwandte Themen:

Geschrieben von
Silvia Schreier
Silvia Schreier
Silvia Schreier ist Consultant bei innoQ und beschäftigt sich seit vielen Jahren mit dem Thema REST und skalierbaren Webarchitekturen. Bei deren Umsetzung bevorzugt sie funktionale Sprachen und NoSQL-Datenbanken. Zu diesen Themen hält sie regelmäßig Vorträge oder schreibt Artikel. Außerdem ist sie Koautorin der dritten Auflage von „REST und HTTP“. Wenn sie nicht gerade neue Technologien ausprobiert, versucht sie bei Initiativen wie Rails Girls, ClojureBridge oder dem Girls’Day andere für Informatik zu begeistern. Twitter: @aivlis_s
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.