Dramatis Personæ

Vorlesung

Marcus Riemer, mri
Florian Schatz, fls (Cloud)

Übung

Hauptamtlich: Marian Gajda, mpg (Framework & Organisation)
Zusätzlich: Heike Hennes, hhe (Aufgaben)
Zusätzlich: Marco Pawlowski, mpa
Zusätzlich: Studentische Abnehmer

Web-Technologien & Web-Anwendungen

Gemeinsam: Verständnis für die technischen Grundlagen von modernen Webseiten

Grundlagen von HTML, CSS & JavaScript

Vertiefung “Web-Anwendungen” (im 4. Semester)

Fortgeschrittenes JavaScript (Funktionsobjekte, Objektorientierung, Promises)
Single Page Applications

Vertiefung “Web-Technologien” (im 2. Semester)

Cloud Hosting
Separates Tutorium bei fls

Grundlegende Programmierkenntnisse erforderlich!

In dieser Veranstaltung werden neue Programmiersprachen eingeführt
Begriffe wie “Schleife”, “Fallunterscheidung” oder “Funktion” sollten Ihnen keine Verständnisschwierigkeiten bereiten.

Ablauf

Vorlesung (3 ECTS)

Zwei Termine
- Mittwochs, 11:00 in HS2
- Mittwochs, 14:00 in HS2
24 mögliche Termine für ~20 Vorlesungseinheiten
- In der Regel: 2 Vorlesungen pro Woche
- Manchmal: Entfall der späteren Vorlesung
Zusätzlich für Hörer “Internet-Technologien”: Tutorium
- Donnerstags, 8:00 in HS3 bei fls
- Keine Vorlesung, stellen Sie Fragen!
Materialien online verfügbar
- Ja, das hier sind die Folien
- Hinweise gerne jederzeit per Mail
  - (Darstellungs?)-Fehler
  - Interessante ergänzende Quellen
  - Themenwünsche

Übung (2 ECTS)

Insgesamt 4 Aufgaben, davon 3 in der Vorlesungszeit
Die ersten drei Aufgaben bauen aufeinander auf
- Zunächst Fokus auf native Web-Technologien ohne Frameworks
Aufgabe 4 unterschiedlich je nach Vertiefung
- Für Web-Anwendungen: Programmierung einer “Single Page Application”
- Für Web-Technologien: Cloud-Infrastruktur
Vorstellung der ersten drei Aufgaben erfolgt im Rahmen der Vorlesung

Klausur

Auf Papier, dauert 90 Minuten
Eingrenzung erfolgt am Ende des Semesters

Historische Entwicklung des Web

Entwicklung in drei größeren Stufen, die Vorlesung folgt dieser Entwicklung

Präsentation von Informationen
Zusätzlich: Bearbeitung von Informationen
Komplexe Applikationen die ausschließlich im Browser dargestellt werden

Jede dieser Varianten ist auch heute noch relevant

Technische Dokumentation (Stufe 1)
Werbe- / Informationsseiten zu bestimmten Produkten (Stufe 1)
Abstimmung und Terminkoordination (Stufe 2)
Kommentarsysteme (Stufe 2)
Soziale Netzwerke (Stufe 3)
Textverarbeitung (Stufe 3)

Das “ursprüngliche” Web

Zeitlich: 1989 - 2001

1989: Erfindung des World Wide Web (WWW) am CERN durch Tim Berners Lee (HTTP, HTML, Webserver, Browser, …)
1995: Internet Explorer und Netscape Navigator für Windows 95
2001: Gründung der Wikipedia

Dominierendes Motiv: Bereitstellung von Dokumenten

Sinngemäß eine Alternative zu Anschlägen am schwarzen Brett oder zu Büchern

Abstrakt: Zugriff auf Informationsressourcen

Hinterlegt als statische Dateien auf Webservern

Menschen als primäre Konsumenten

Verwendung eines “User Agents” (Webbrowser)

Eindeutige Identifikation von Ressourcen über Namen und Adressen

Konzept der Hyperlinks

Formatierung von Inhalten mit HTML

Textauszeichnungssprache zur Beschreibung von statischen Webseiten

Das “Web 2.0”

Zeitlich: 2001 - 2009

2001: Gründung der Wikipedia
2006: Standarisierung des XMLHttpRequest für AJAX
2009: Initiale Veröffentlichung von Angular JS

Anlegen von Informationsresourcen

Benutzer können das Internet direkt über Ihren Browser erweitern (Wikipedia, Blogs, …)

Typisch: Serverseitige Erstellung von dynamischen Webseiten

PHP, Perl, Java, …

Zunehmend: Maschine-Maschine Kommunikation über das Web

Konzept der “Webservices” welche einfach nur Rohdaten bereitstellen, keine Dokumente

Möglich: Clientseitige Dynamik mit AJAX

Interaktion im Client (Knopf drücken, Link folgen, …) lädt die Seite nicht notwendigerweise neu

Single Page Applications

Zeitlich: 2009 - Heute

2009: Initiale Veröffentlichung von Angular JS
2009: Google bezeichnet die ursprüngliche Version von “Google Docs” als stabil
2011: Facebook führt den “Messenger”, dieser läuft vollständig eingebettet in den “normalen” Webauftritt

Wesentliches Merkmal: Darstellung der Seite findet ausschließlich im Browser statt

Server liefert aus:

Programm zur Steuerung der Darstellung
Darzustellende Daten

Heute: Entwicklung solcher Browser-Anwendungen als Alternative zu nativen Programmen

Entwicklung nicht komplexer als z.B. mit JavaFX, Windows Forms, WPF oder Qt

Themen

Ergeben sich aus der Startseite

Leitmotiv: Entwicklung moderner Webanwendungen mit HTML5 & Javascript

Explizite Nicht-Themen

PHP wäre zwar fraglos relevant, aber leider ist nur Zeit für eine Programmiersprache
Adobe Flash ist mittlerweile für neue Projekte nicht mehr relevant
Wordpress ist technisch gesehen nur eine weitere PHP-Anwendung

Inhalte der Übung

Übergeordnetes Thema: Wir bauen einen Webshop: Etwas präziser: Wir stellen Waren aus, kümmern uns aber nicht um den Bezahl- oder Versandprozess

Aufgabe: HTML, CSS & Templating

Reine Präsentation der Waren, keinerlei Benutzerinteraktion
Aufgabe: Serverseitige Dynamik

Kommentare & Bewertungen hinterlassen, Warenkorb
Aufgabe: Clientseitige Dynamik

Animationen & AJAX

Technische Grundlagen

Grundsätzlich: Alle clientseitigen Aspekte einer Web-Anwendung / einer Webseite lassen sich im Browser untersuchen

Jeder Browser bietet Entwicklerwerkzeuge
Jedoch keine Zugriff auf den Quelltext des Servers

HTTP: Hypertext Transfer Protocol

Zum Austausch der Daten zwischen Server & Client

HTML: Hypertext Markup Language

Zur Auszeichnung der Dokumente im Browser
Gibt den Inhalten (Texten) eine Struktur

CSS: Cascading Stylesheets

Zur Anpassung der Darstellung im Browser

JavaScript

Auf dem Server: Erzeugen von HTML-Seiten
Auf dem Client: Reaktion auf Ereignisse, Änderungen an der Dokumentstruktur

Webserver

Ein beliebiger Rechner mit Internetanschluss

Dezidierte IP von Vorteil, aber nicht nötig

Typisch: Verwendung einer Server-Software, niemand sollte HTTP-Server von Hand schreiben

Sehr typisch: Verwendung eines symbolischen Namens (“Domain”)

Maschinen konnten schon vor dem WWW-adressiert werden, das Domain-Name-System (DNS) ging 1983 in Betrieb

Konzept der virtuellen Hosts (vhost)

Mehrere Webauftritte auf einem einzelnen Server

Ohne Nutzung von Domains: Nur eine Seite je Kombination aus IP und Port

Server kann Anfrage ohne Domainangabe nicht zuordnen
Typisches Vorgehen während der Entwicklung

Browser / Client / User Agent

Typisch: Verwendung einer Browser-Software, niemand sollte HTML-Darstellung von Hand versuchen

Firefox
Chrome
Edge
Internet Explorer
Safari
…

Identifikation von Resourcen

Welche konkrete Resource auf dem Server soll abgerufen werden?

Analog zum Dateisystem: Pfadangabe

Uniform Resource Identifier / Name / Locator

URI ist der Oberbegriff für URN und URL
URN identifizieren Ressourcen eindeutig, geben aber keinen Ort an (z.B. ISBN Nummern)
Unterschiedliche URLs können auf identische Ressourcen verweisen, geben den Speicherort an

Praktisch relevant: Uniform Resource Locator (URL)

Eindeutige, stabile Bezeichner (cool URIs dont change)

Anzeige in der Adresszeile des Browsers

Je nach Browser andere, vereinfachte Darstellungen

Beispiele für URLs

Dateisystembrowser mit Benutzerangabe

https://mri@stud.fh-wedel.de/handout/

Angabe von Suchparametern

http://www.hearthpwn.com/cards?filter-name=Murloc&filter-class=256

Abbildung des Seitenbaums

Allgemeines Problem: Eindeutige Bezeichner für Ressourcen

Benutzer merken sich nicht gerne Zahlen
Maschinen vergleichen nicht gerne Strings

HTTP Uniform Resource Locator


       |------------------ Schema-spezifischer Teil ------------------|
 https://mri:secret@www.fh-wedel.de:8080/index.html?p1=A&p2=B#ressource
 \___/   \_/ \____/ \_____________/ \__/\_________/ \_______/ \_______/
   |      |    |           |         |       |          |         |
Schema⁺   | Kennwort      Host      Port    Pfad      Query    Fragment
       Benutzer

Struktur einer HTTP-URL

Schema definiert Format des Protokolls

Im Rahmen dieser Veranstaltung HTTP und HTTPS

Benutzer & Kennwort zur Authentifizierung

Können im Falle einer Authentifizierung mit HTTP Basic Auth als Teil der URL kodiert werden

Host, wahlweise als Name oder IP-Adresse

Normalerweise sind Namen gegenüber IPs zu bevorzugen:

Besser zu merken
Zahlreiche Webserver liefern unter einer IP unterschiedlichste Webseiten aus

Port zur numerische Differenzierung unterschiedlicher Angebote

Vorsicht: In einigen Netzwerken dürfen nur die Ports 80 & 443 zur HTTP-Kommunikation verwendet werden

Hierarchischer Pfad um die Resource eindeutig zu identifizieren

Entspricht möglicherweise, aber nicht zwangsläufig, dem Dateisystem des Webservers

Query zum Übertragen von Aufrufparametern

Enge Verbindung mit Formularen

Fragment zur Navigation zu bestimmten Inhalten einer Seite

Navigation innerhalb umfangreicher Seiten

Relative und absolute Angaben

Unvollständige URLs können im Kontext einer Elter-URL interpretiert werden

Elter-URL ist typischerweise die Adresszeile des Browsers

Große Hilfe bei der Notation im Quelltext

Vermeidet redundante Angaben

Absolute und relative Pfadangaben

Pfade werden, wie im Dateisystem, für sich betrachtet als absolut oder relativ bezeichnet
Beginnt ein Pfad mit einem / so bezieht er sich auf die Wurzel der Pfadhierarchie
Mit .. in einer Pfadangabe wird eine Ebene nach “oben” navigiert

Protokoll-relative Angaben beginnend mit //

Austausch des Hosts bei Verwendung des identischen Protokolls

Beispiele zu absoluten und relativen Angaben

Absolute Elter-URL: "http://example-blog.test/all/"
 
"#footer"            => "http://example-blog.test/all/#footer"
"?start_at=4"        => "http://example-blog.test/all/?start_at=4"

"impressum"          => "http://example-blog.test/all/impressum"
"../impressum"       => "http://example-blog.test/impressum"
"/impressum"         => "http://example-blog.test/impressum"
"../?fast_mode=1"    => "http://example-blog.test/?fast_mode=1"

"//fh-wedel.de"      => "http://fh-wedel.de"

Wesentliche Nutzung: Angabe des Hostnamens vermeiden: Seite funktioniert dann gleichermaßen gut unter verschiedenen Domain- oder IP-Angaben

Escaping

Reservierte Zeichen

! * ' ( ) ; : @ & = + $ , / ? # [ ]

Zulässige “Nutzzeichen”

Trivial: A - Z, a - z und * - _ . ~

Alle anderen Zeichen müssen separat kodiert werden

Insbesondere also Umlaute und Leerzeichen

%-Kodierung anhand der hexadezimal notierten ASCII-Werte

%20 entspricht einem Leerzeichen, %21 entspricht !, …
http://fh-wedel.de/~eh/?query=Alter, wie besteht man Analysis? wird zu http://fh-wedel.de/~eh/?query=Alter%2C%20wie%20besteht%20man%20Analysis%3F

Das `HTTP`-Protokoll

Verbreitetste Version: HTTP 1.1, optional mit Verschlüsselung (HTTPS): TCP-Klartextprotokoll mit Kopf- und Nutzdaten
Zustandsloses Protokoll für eine Anfrage mit einer Antwort: Server schließt möglicherweise die Verbindung, wenn die Anfrage bearbeitet wurde
Aktuelle Version: HTTP 2: Verschlüsseltes TCP-Binärprotokoll mit Kopf- und Nutzdaten

Exkurs: `CRUD`-Zyklus

Begriff der “Ressource”

Beliebiges Geschäftsobjekt mit Daten und Operationen

Grundidee: Jede Ressource durchläuft vier Phasen

Mit CREATE wird die Resource angelegt
Dann wird sie mindestens einmal gelesen (READ)
Wenn äußere Umstände eine Veränderung notwendig machen, werden diese durchgeführt (UPDATE)
Und schließlich kann die Resource gelöscht werden (DELETE)

`HTTP`-Verben

Jede Anfrage nutzt ein Verb, um den Zweck der Anfrage zu verdeutlichen

GET dient zum Abruf von Daten, Veränderungen sind nicht vorgesehen
HEAD weist den Server an, die Abfrage wie bei GET auszuführen, allerdings nur mit den Kopfdaten zu antworten
POST sendet eine theoretisch beliebig große Datenmenge an den Server um sie dort verarbeiten zu lassen
PUT dient zum Erstellen einer neuen Resource auf dem Server
PATCH dient zum Verändern einer bestehenden Resource auf dem Server
DELETE löscht eine Resource vom Server

Verben haben Entsprechungen im CRUD-Zyklus

CREATE entspricht PUT oder POST
READ entspricht GET
UPDATE entspricht PATCH oder PUT
DELETE entspricht DELETE

Nicht jede Phase muss exakt einem HTTP-Endpunkt oder einer Funktion entsprechen!

Insbesondere UPDATE-Operationen sind häufig abhängig von Benutzerrechten

`HTTP`-Statuscodes

Numerischer Code als Ergebnis jeder Abfrage

Wird zusätzlich zum eigentlichen Inhalt übertragen

Code 1xx - Informationen

Anfrage noch nicht verarbeitet

Code 2xx - Erfolg

200 - OK Anfrage wurde erfolgreich verarbeitet, das Ergebnis wird übertragen

Code 3xx - Umleitung

300 - Multiple Choices Der Anfragesteller muss die korrekte Resource auswählen
301 - Moved Permanently Die neue Adresse steht im Location-Feld

Code 4xx - Clientfehler

400 - Bad Request Allgemein ungültige Anfrage
401 - Unauthorized Authentifizierung erforderlich, das Feld WWW-Authenticate enthält weitere Informationen
403 - Forbidden Berechtigung nicht ausreichend
404 - Not Found
405 - Method Not Allowed Falsches HTTP-Verb

Code 5xx - Serverfehler

500 - Internal Server Error Unbekannter Fehler an unbekannter Stelle
503 - Service Unavailable Temporäre Überlastung

Eine `HTTP`-Anfrage

Vorab: Verbindung zum Server herstellen: Zum Beispiel mit telnet $host $port

Zeile 1 & 2

Anfrage des Clients, beginnt mit GET und nennt zusätzlich explizit Host

Zeile 4 - 12

Kopfdaten der Antwort

Zeile 4

HTTP-Antwort, es ist alles OK

Zeile 7

Content-Type beschreibt anhand von MIME-Typen wie die Antwort zu interpretieren ist

Zeile 8

Content-Length enthält die Länge der Antwort in byte

Zeile 14+

Nutzdaten, in diesem Fall ein HTML-Dokument

basics/http-request.http

GET /tribute/ HTTP/1.1
Host: mri.fh-wedel.de

HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Sun, 09 Apr 2017 11:55:48 GMT
Content-Type: text/html
Content-Length: 792
Last-Modified: Sat, 08 Apr 2017 15:03:40 GMT
Connection: keep-alive
ETag: "58e8fbcc-318"
Accept-Ranges: bytes

<!DOCTYPE html>
<!-- -->

Beispiel: `URL`-Struktur einer Homepage

Grundidee: Eigene Homepage meine-seite.test mit drei Bereichen

Statische Seiten
Neuigkeiten
Bildergalerien

Statische Seiten

Hauptseite (index)
Lebenslauf

Sonderfunktionen

Suche
Geheimes Tagebuch

Statische Seiten

Neuigkeiten

Bisher folgende Artikel

“Superpapagei” vom 24.6.2016
“Der Phantomsee?” vom 13.8.2016
“Auf du und du mit dem Karpatenhund” vom 31.12.2016

Festlegung des übergeordneten Pfadsegments: artikel

Alle Artikel unter meine-seite.test/artikel

Variante: Eindeutige IDs für jeden Artikel
- Basierend auf der Veröffentlichungsreihenfolge
- “Superpapagei” unter meine-seite.test/artikel/1
Variante: Schlagzeile als ID für Artikel
- “Superpapagei” unter meine-seite.test/artikel/superpapagei
- Problematisch: Artikel sollte nicht umbenannt
Variante: Eindeutige ID für Artikel, aber Schlagzeile zur besseren Lesbarkeit (Redundant)
- “Superpapagei” unter meine-seite.test/artikel/1/superpapagei
- “Der Phantomsee” unter meine-seite.test/artikel/2/der-phantomsee
- Was ist unter meine-seite.test/artikel/3/superpapagei?
Variante: Kodierung des Datums
- “Superpapagei” unter meine-seite.test/artikel/2016/6/24/superpapagei

Kanonische Schreibweisen & Slugs

Sonderzeichen bei in URLs verwendeten Namen machen kanonische Schreibweise nötig

Groß- und Kleinschreibung
Leerzeichen
&, /, ?

Können automatisch generiert oder manuell gewählt werden

Déjà-vu: Die Katze war doch eben schon da? -> deja-vu-die-katze-war-doch-eben-schon-da
Löschen von Dateien unter C:/Windows -> loschen-von-Dateien-unter-c-windows

Seitenbaum erweitert um Artikel

Statische Seiten und Artikel

Galerie

Bisher folgende Galerien

“Rocky Beach Comicmesse” vom 22.6.2016
“Verleihung des goldenen Raben” vom 12.2.2017

Prinzipiell die gleichen Möglichkeiten wie für Artikel

Zur Verfügung stehende Informationen sind identisch

Dateinamen für Bilder?

Originale Namen?
Nummeriert?

Speicherung einzelner Bilder?

Zentral unter z.B. /bilder/:bild
Als Teil der Galerie: /galerie/2016-comicmesse/:bild
Unter einer Subdomain: bilder.meine-seite.test/:bild

Seitenbaum erweitert um Galerien