Moderne Webanwendungen für .NET-Entwickler E-Book

Holger Schwichtenberg

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch
• Veröffentlichungsjahr: 2018

Seitenzahl: 1051

Beschreibung

Auch in der .NET-Welt werden immer mehr Web- und Cross-Plattformanwendungen mit HTML, CSS, JavaScript/TypeScript und SPA-Frameworks clientseitig programmiert, während auf dem Server ASP.NET oder ASP.NET Core zum Einsatz kommt. Das erfahrene  IT-Visions.de-Expertenteam um Dr. Holger Schwichtenberg zeigt, wie Sie mit diesem Technikmix moderne Single-Page-Webanwendungen und mobile Cross-Platform-Apps realisieren. Es liefert Praxiswissen für Entwickler, die bislang Windows-Desktop-Anwendungen entwickelt haben oder nur mit älteren ASP.NET-Konzepten (Webforms) vertraut sind. Das Buch deckt ein umfassendes Themenspektrum ab: Web-Basiswissen: HTML und CSS, das Framework Bootstrap, das von CSS abstrahiert und von Microsoft in den Projektvorlagen für ASP.NET und ASP.NET Core eingesetzt wird. Webserverprogrammierung mit ASP.NET: das klassische Framework ASP.NET Model-View-Controller (MVC) und das klassische Web API ASP.NET sowie ASP.NET SignalR, die auf dem .NET Framework 4.x und nur auf Windows-Systemen laufen. Webserverprogrammierung mit ASP.NET Core: das neue ASP.NET Core inklusive WebAPI und SignalR Core, das auf dem Windows-basierten .NET "Full" Framework 4.x oder dem plattformneutralen .NET Core läuft. Inklusive einer Fallstudie zu Microservices mit ASP.NET Core Web API und RabbitMQ. Web-Client-Programmierung: Einführungen in die Programmiersprachen JavaScript und TypeScript und die Single-Page-Web-Frameworks Angular und React sowie ASP.NET Blazor, das auf C# aufbauende SPA-Framework. Hosting von ASP.NET und ASP.NET Core: Self-Hosting sowie Hosting in den Internet Information Services (IIS), in Docker-Containern und über den Microsoft-Cloud-Dienst Azure. Das Fallbeispiel MiracleList: komplettes Fallbeispiel einer modernen Webanwendung, bestehend aus einem Backend (C# mit ASP.NET Core), einem Web-Frontend (TypeScript mit Angular) sowie Cross-Platform-Apps für Linux, macOS, Windows, Android und iOS (mithilfe von Electron und Cordova aus dem Web-Frontend erzeugt). Bonuskapitel: Sie erhalten zusätzlich drei Kapitel zu React, Open Web Interface for .NET (OWIN) / Katana und ASP.NET Sicherheit als kostenloses PDF zum Herunterladen.

Leseprobe

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

3., aktualisierte Auflage

Moderne Webanwendungen für .NET-Entwickler

Server-Anwendungen, Web APIs, SPAs & HTML-Cross-Platform-Anwendungen mit ASP.NET, ASP.NET Core, JavaScript, TypeScript & Angular

mit Beiträgen von Dr. Holger Schwichtenberg, Jörg Krause, Dr. Joachim Fuchs, Sebastian Kleinschmager und Manfred Steyer

Holger Schwichtenberg und Jörg Krause

Lektorat: Ariane Hesse

Korrektorat: Claudia Lötschert, www.richtiger-text.de

Satz: Gerhard Alfes, mediaService, Siegen, www.mediaservice.tv

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Bibliografische Information Der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-96009-015-1

PDF    978-3-96010-258-8

ePub   978-3-96010-259-5

mobi   978-3-96010-260-1

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

3., aktualisierte Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.

Inhalt

Vorwort zur 3. Auflage

Warum dieses Buch?

Was ist der Inhalt dieses Buchs?

Welche Voraussetzungen sollten Sie für dieses Buch mitbringen?

Was ist das Ziel des Buchs?

Welche Versionen werden in diesem Buch behandelt?

Welche Programmiersprache wird in diesem Buch verwendet?

Welche Werkzeuge werden in diesem Buch verwendet?

Welche Sprachversion wird in diesem Buch verwendet?

Woher bekommen Sie die Code-Beispiele und die drei Bonuskapitel zu diesem Buch?

Wem ist zu danken?

Die Autoren

Teil AWeb-Basiswissen

1Protokolle, Standards und Konzepte

Standardisierung

RFCs

World Wide Web Consortium (W3C)

European Computer Manufacturers Association (ECMA)

Hypertext Transfer Protocol (HTTP)

Protokollaufbau, Header, Body

Kommandoaufbau

Die HTTP-Statuscodes

Ablauf einer HTTP-Kommunikation

Kopffelder

HTTP 2.0

Ergänzende Standards zu HTTP

Web-Sockets

WebDAV

Simple Mail Transfer Protocol (SMTP) oder Extended SMTP (ESMTP)

File Transfer Protocol (FTP)

REpresentational State Transfer (REST)

Webdienste

Merkmale

REST-Beispiel

URI

HTTP-Methoden für REST

Multipurpose Internet Mail Extensions (MIME)

JavaScript Object Notation (JSON)

Atom Syndication Format (ATOM)

Grenzen von REST: GraphQL und OData

Single Page Application (SPA)

Asynchronous JavaScript and XML (AJAX)

Responsive Web Design (RWD)

2Hypertext Markup Language (HTML)

Grundlagen HTML

Geschichte

XML – Grundlage für HTML

Markup

XML-Dokumente

Verarbeitung

Der Begriff »Markup«

Seitenaufbau

Document Object Model (DOM)

Der Dokumenttyp (Doctype)

Codierungen

HTML5-Seitenstruktur

Elemente der Seite

Textelemente

Fließtextauszeichnung

Verweise

Tabellen

Multimedia und Grafiken

Formulare

Skripte

Interaktive Elemente

Allgemeine und universelle Attribute

id

class

accesskey

contenteditable

contextmenu

dir

draggable

dropzone

hidden

lang

spellcheck

style

tabindex

title

3Cascading Style Sheets (CSS)

Grundlagen

Syntax

Selektor

Elemente (Tags)

ID

Klassen

Attribute

Logische Auswahl

Weitere Selektoren

Das Box-Modell

Bausteine der Box

Zählweise

Ausnahmen

Das Box-Modell in CSS3

Das Flexbox-Modell

Prinzipien

Eigenschaft der Container

Beachtung von Medien

Syntax

Parameter

Der Viewport

Viewport einstellen

Parameter für den Viewport

Einheiten

Absolute Einheiten

Relative Einheiten

4Bootstrap

Einführung in Bootstrap

Neuerungen in Bootstrap 4

Installation

Struktur der CSS-Dateien

Seitenaufbau

Browserunterstützung

ARIA

Optimierung

Hilfsklassen

Reboot

Struktur der Seite

Einführung

Das Rastersystem

Das Flex-Raster

Typografie

Überschriften

Text und Textelemente

Listen

Tabellen

Hilfsklassen

Formulare

Struktur eines Formulars

Eingabeelemente

Schaltflächen

Weitere Bausteine

Symbole

Responsive Bilder

Eingebettete Quellen

Farben und Hintergründe

Ausrichtung von Elementen im Fluss

Inhalte anzeigen und verstecken

Komponenten

Klappmenüs (dropdown)

Werkzeugleisten (toolbar)

Schaltfläche mit Menü (button group)

Navigation (nav, navbar)

Pfadnavigation (breadcrumb)

Seitenweises Blättern (pagination)

Kennzeichnungen (tag)

Großbildleinwand (jumbotron)

Seitenüberschriften (page header)

Meldungen (alert)

Fortschrittsbalken (progress)

Medien (media)

Allgemeine Listen (list group)

Karten (cards)

Aktive Komponenten

Einrichtung und Aktivierung

Die Programmierschnittstelle

Übergänge (transition)

Modale Dialoge (modals)

Klappmenü (dropdown)

Scrollbar-Überwachung (scrollspy)

Angeheftete Navigation (affix)

Umschaltbare Tabulatoren (tab)

Tooltips (tooltip)

Inhaltsüberlagerung (popover)

Meldungen (alert)

Interaktive Schaltflächen (button)

Inhaltseinblendung (collapse)

Bilderkreisel (carousel)

Teil BWebserverprogrammierung mit ASP.NET

5ASP.NET MVC

Geschichte und Verbreitung von ASP.NET

Architektur von ASP.NET MVC

Erste Schritte mit ASP.NET MVC

ASP.NET-MVC-Projekt anlegen

Projektaufbau

Nuget-Pakete

Controller anlegen

View anlegen

Webanwendung testen

Einträge editieren

Vorschlagswerte über Drop-down-Listenfelder anbieten

Controller

Models entgegennehmen

View auswählen

Auf Ausnahmen reagieren

URL-Mapping beeinflussen (Routing)

Asynchrone Controller

Vereinfachte Implementierung asynchroner Controller seit .NET 4.5

Views

Razor

Razor-Helper

Layoutseiten

Partielle Views

Vorlagen für Felder und Models

Views für mobile Anwendungen

Zwischen unterschiedlichen Ansichten wechseln

Minification und Bundling

Models

Metadaten im Model festlegen

HTML-Text übermitteln

Validieren von Benutzereingaben

Globalisierung

Sprach- und Ländereinstellungen festlegen

Über Ressourcedateien mehrsprachige Inhalte bereitstellen

Codierung festlegen

Areas

Filter

Überblick

Umsetzung

Filter auf Controller und Action-Methoden anwenden

Globale Filter

Authentifizierungsfilter

6ASP.NET Web API

Einen einfachen HTTP-Service erstellen

Parameter und Rückgabewerte

HTTP-Services konfigurieren

HTTP-Services mit Fiddler testen

Mehr Kontrolle über HTTP-Nachrichten

Antworten mit HttpResponseMessage beeinflussen

Anfragen als HttpRequestMessage darstellen

HttpRequestMessage und HttpResponseMessage am Beispiel Conditional Get

Antworten über IHttpActionResult zurückgeben

HTTP-Services über HttpClient konsumieren

Routing

Benutzerdefinierte Routen über die Konfiguration festlegen

Attributbasiertes Routing

Weiterführende Schritte mit der Web API

Dynamische Parameter

Tracing

Request Batching

Cross Origin Resource Sharing (CORS)

Validieren

Querschnittsfunktionen implementieren

Message-Handler

Filter

Filterüberschreibungen

Benutzerdefinierte Formate unterstützen

Formatter implementieren

Formatter mit HttpClient verwenden

Serialisierung beeinflussen

JSON-Serializer konfigurieren

XML-Serializer konfigurieren

Eigenschaften von der Serialisierung ausschließen

Zirkuläre Referenzen serialisieren

Binary JSON (BSON)

Web API und HTML-Formulare

Einfache Formularfelder übermitteln

Datei-Upload via HTML-Formular

Fortschritt ermitteln

Feingranulare Konfiguration

Controllerbasierte Konfiguration

Routenbasierte Konfiguration

7ASP.NET SignalR

Long-Polling

Web-Sockets

Überblick über ASP.NET SignalR

PersistentConnection

Erste Schritte mit SignalR und PersistentConnection

Lifecycle-Methoden

URL-Mapping für persistente Verbindungen

Einfacher Client für eine persistente Verbindung

Einfacher JavaScript-Client für eine persistente Verbindung

Hubs

Methoden und Callbacks mit SignalR und Hubs

URL-Mapping für Hubs

Lifecycle-Methoden

Hubs konsumieren

Hubs über JavaScript konsumieren

Gruppen

Pipeline-Module für Querschnittsfunktionen

SignalR konfigurieren

Cross Origin Resource Sharing (CORS)

SignalR skalieren

Überlegungen zum Skalieren von SignalR

SignalR mit SQL Server skalieren

Implementierung eines SignalR-Clients

Das Skalierungsszenario testen

Azure Service Bus und Redis als Alternative zu SQL Server

8ASP.NET-Programmierschnittstellen

Direkt mit HTTP interagieren

HttpContext

Server (HttpServerUtility)

Request (HttpRequest)

Response (HttpResponse)

Zustandsverwaltung auf Sitzungsebene

Überblick

Weitere Optionen

Programmieren mit dem Sitzungszustand

URL-basierte Sitzungsverwaltung ohne Cookies

Konfiguration des Sitzungszustands

Speicherort der Sitzungstabelle wählen

Komprimierung des Sitzungszustands

Deaktivieren des Sitzungszustands

Caching

Überblick

Pro und Contra der Zwischenspeicherung

Zwischenspeicherung ganzer Seiten (Output-Caching)

Caching von Seitenteilen (Fragmentzwischenspeicherung)

Programmatisches Caching

Cacheinvalidierung

Teil CWebserverprogrammierung mit ASP.NET Core

9Einführung in ASP.NET Core

Klassisches ASP.NET oder ASP.NET Core?

Einführung in die Core-Welt

.NET Standard

Windows Compatibility Pack für .NET Core

Open Source

Dokumentation

Werkzeuge

Kommandozeilenwerkzeug dotnet

Editoren

Erste Schritte mit ASP.NET Core (auf .NET Core)

Installation

Projekt anlegen

Projektaufbau

Die Klasse Program

Klasse Startup und Middleware

Referenzen/Pakete

Übersetzen und Debugging

Deployment

ASP.NET Core auf dem klassischen .NET Framework

Einsatzszenarien

Anlegen von ASP.NET-Core-Projekten mit dem klassischen .NET Framework

Projektaufbau

Referenzen/Pakete

Deployment

In ASP.NET Core integrierte Webserver: Kestrel versus HTTP.sys (WebListener)

Kestrel

HTTP.sys

10ASP.NET Core MVC und Razor Pages

POCO-Controller

Controller und View

Tag Helper

Wie funktionieren Tag Helper?

Eingebaute Tag Helper

Eigene Tag Helper

Beispiel: Tag <autor>

Beispiel: Tag <row>

Beispiel: Tag <condition>

Beispiel: Tag <repeater>

View Components

Razor Pages

Von Webforms über MVC zu Razor Pages

Razor Pages versus MVC

Page Model als Code-Behind

URL-Parameter

Eingebaute Objekte

Datenbindung

Praxisbeispiel zu Razor Pages

Drittanbieterkomponenten für ASP.NET Core

11ASP.NET-Core-Klassenbibliotheken

Dependency Injection in ASP.NET Core

Implementierung eines Diensts

Registrierung von Diensten

Injektion in einen Konstruktor

Manuelle Beschaffung

Injektion in eine View

Vordefinierte Dienste der ASP.NET-Core-Infrastruktur

Konfiguration in ASP.NET Core

Sitzungen in ASP.NET Core

Cookies

URL-Rewriting in ASP.NET Core

Benutzerverwaltung und Authentifizierung

12ASP.NET Core Web APIs

Die Grundlagen von ASP.NET Core Web API

Abfragen von Daten

Arbeiten mit Statuscodes

Anlegen, Aktualisieren und Löschen von Daten

Nutzung von Sub-Routen für Teil-Ressourcen

Nutzung weiterer Model-Binding-Funktionen

Anbieten unterschiedlicher Repräsentationen von Ressourcen

Nutzung des PATCH-Verbs mit JSON-Patch

Cross Origin Resource Sharing

Bereitstellung von OpenAPI-Beschreibungen über Swagger

Starten von Hintergrundprozessen über IHostedService

Integrationstests mithilfe des TestHosts

Service-Kommunikation mit HttpClient

Abfragen von Daten

Versenden von Daten und Reaktion auf Statuscodes

Arbeiten mit Headern und HttpRequestMessage

Generieren von Clients für Swagger-Spezifikationen

Ausblick auf Neuerungen durch ASP.NET Core 2.1

Annotation [ApiController]

ActionResult<T>-Rückgabewerte

Optimierte Input-Verarbeitung

13Microservices mit ASP.NET Core Web API und RabbitMQ

Grundlagen von Microservices

Mögliche Vorteile von Microservices

Mögliche Nachteile von Microservices

Modellierung von Microservices

Integration und Kommunikation von Microservices

Synchrone und asynchrone Kommunikation

Messaging-basierte versus Request-Response-Kommunikation

Gesteuerte (orchestriert) versus Event-getriebene Kommunikation (choreografiert)

.NET-Core-Technologien zur Umsetzung von Service-Kommunikation

Asynchrone Service-Kommunikation über RabbitMQ

Microservices-Fallstudie

Umgebung und fachlicher Kontext

Der HumanResourcesService

Der ProjectsService

Der ManagementDashboardService

Der InvoicingService

Fazit

Nützliche Patterns und Best-Practices im Bereich Microservices

Resilienz-Patterns

Serviceübergreifender Code und serviceübergreifende Funktionen

14ASP.NET Core SignalR

Hub-Klassen

Hub-Client mit .NET Core 2.1

Hub-Client mit Angular

Serverseitig initiierte Benachrichtigungen und Gruppen

Teil DWeb-Client-Programmierung

15JavaScript-Grundlagen

Grundlagen der Sprache

Sprachmerkmale und Entwurfsmuster

Vergleich mit Programmiersprachen

JavaScript-Syntax

Typen

Objekte

Symbole

Arrays

Operatoren

Anweisungen – Statements

Fehlerbehandlung

Variablen und Scope

Objektorientierung

Erstellen von Objekten

Klassen

Statische Mitglieder

Vererbung

Exkurs Objekthierarchie

Ableiten von internen Typen

Tipps zum Umgang mit objektorientierten Techniken

Globale Standardfunktionen

Timer-Funktionen

Prüffunktionen

Konvertierungsfunktionen

Module

Entwurfsmuster

Module

Funktionen

Pfeilfunktionen (Lambdas)

Erweiterte Objektliterale

Destrukturierung

Umgang mit Argumenten

Generatoren und Iteratoren

Asynchrone Programmierung

Klassische asynchrone Programmierung

Promise

Set und Map

Set

Map

Schlüsselvergleiche

Iteratoren

WeakMap und WeakSet

Reguläre Ausdrücke

Einführung

Kopieren oder Konstruieren?

Und wie funktioniert das?

Gruppierungen

Vorwärtsreferenzen

Die JavaScript-Funktionen

Zusammenfassung

Reflektions-API

Einfache Methoden

Reflect

Erzeugerfunktionen

Operatoren für Schlüsselwörter

Dynamische Argumentlisten

Funktionsaufrufe

Proxy-Fallen

Zusammenfassung der Reflect-Methoden

Stellvertreter: Proxies

Einführung

Proxy-Fallen anwenden

Schemaprüfung mit Proxies

Entfernbare Proxies

Übersicht

16TypeScript

Geschichte von TypeScript

Open-Source-Projekt

TypeScript-Compiler

Übersetzung von TypeScript in JavaScript

TypeScript Playground

TypeScript in Visual Studio

TypeScript-Kommandozeilencompiler tsc

TypeScript in Visual Studio Code

TypeScript in Gulp

Datentypen

Arrays und Tupel

Klassen

Generische Klassen

Strukturelle Typäquivalenz (Duck Typing)

Funktionen und Lambda-Ausdrücke

Dekoratoren

Module und Verweise

TypeScript ohne externes Modulsystem (interne Module)

Externe Module

Re-Export

Deklarationsdateien

Einbindung von Deklarationsdateien (altes Verfahren)

Import von Deklarationsdateien

Deklarationsdateien und tsconfig.js

Mixins

Mixin-Konstruktortypen

Deklaratives Mischen

Module mischen

Nicht mögliche Vermischungen

Reflektion: Metadaten per Programmcode

Die Metadaten-API für Reflektion

Ermitteln von Typinformationen

Ermitteln von Parameterinformationen

Ermitteln von Rückgabeinformationen

Asynchrone Programmierung

Generatoren und Iteratoren

Iteratoren

Generatoren

Asynchrone Iteration

Asynchrone Generatoren

17Angular

Ziele und Architektur von Angular

Browserunterstützung

Veröffentlichungszyklus von Angular

Dokumentation

Beispielsammlung

Komponenten

Datenbindung und Pipes

Syntaxübersichten

Strukturelle Direktiven

Datenbindungssyntax

Angular-Pipes

Module

Formulare

Routing

Dienste und Dependency Injection

Animationen

Werkzeuge

JiT vs. AOT

Angular Universal

18ASP.NET Blazor

Silverlight wurde eingestellt

Web Assembly

Architektur von Blazor

Erste Schritte mit ASP.NET Blazor

Beispielprojekt

Weitere Möglichkeiten

Ausblick

Teil EHosting von ASP.NET und ASP.NET Core

19Internet Information Services (IIS)

Versionsgeschichte

Kernfunktionen des IIS

Installation des IIS

Modularisierung

Skriptbasierte Installation

Integration zwischen ASP.NET und IIS

Test der Installation

IIS Express

IIS-Administration

IIS-Manager

Administration per Kommandozeile und Skript

IIS-Websites (virtuelle Webserver)

Websites erstellen

Websites erstellen per Skript

Wichtige Einstellungen für Websites

Beschränken der möglichen Clients

Authentifizierung

Transport Layer Security (TLS)/Secure Socket Layer (SSL)

Server für Nicht-HTTP-Protokolle

Virtuelle Verzeichnisse im IIS

IIS-Anwendungen

Rahmenbedingungen einer IIS-Anwendung

Anlegen einer IIS-Anwendung

IIS-Anwendungspools

Eigenschaften eines Anwendungspools

Liste der Anwendungspools

Zuordnung von Websites und IIS-Anwendungen zu Anwendungspools

ASP.NET-Version

Erweiterte Einstellungen für Anwendungspools

Anwendungspoolidentität

Wiederverwendung (Recycling)

Leistungseinstellungen

Zustandsüberwachung

Besonderheiten für ASP.NET-Anwendungen

IIS-Autostart

IIS-Verarbeitungspipeline

20Microsoft Azure

Azure-Konzepte

Anlegen einer Subscription

Anlegen einer Ressource Group

Anlegen eines App Service Plans

Anlegen eines Azure App Service

Anlegen eines Azure App Service mit der PowerShell

21Verteilen von Webanwendungen aus Visual Studio heraus

Web Deploy-Werkzeug

Web Deploy in einen IIS-Webserver

Web Deploy nach Azure

Konfigurationstransformationen

Erstellen der Transformationsdateien

Syntax der Transformationsdateien

Ergebnis der Transformation

Continuous Integration und Continuous Delivery

22Webanwendungen in Docker

Docker auf Windows

Installation der Docker-Unterstützung von Microsoft

Installation von Docker for Windows

Ein Image beschaffen

Einen Container starten

Ein Visual-Studio-Container-Projekt erstellen

Debugging eines Containers

Verwendung des Containers

Images aus Containern erstellen

.NET Core-Container

Container in Windows Server 2016 hosten

Images verbreiten

Teil FFallbeispiel: MiracleList

23Das Fallbeispiel »MiracleList«

Das Szenario

Links

24Das MiracleList-Backend

Architektur

Entitätsklassen

Entity Framework Core-Kontextklasse

Lebensdauer der Kontextklasse in ASP.NET Core-Anwendungen

Geschäftslogik

Web API

25MiracleList-Web-Client

Technikeinsatz im Web-Client

Angular-CLI

Webserver starten

Zusatzkomponenten

Proxy für REST-Dienste

Daten darstellen

Navigation zu den Aufgaben

Datumsanzeigen

Zeilenumbrüche

Aufgabenstatus ändern

Aufgaben anlegen

Suchfunktion

Komponentenbildung

Schritt 1: Routing-Modul

Schritt 2: Kommunikationsdienst

Schritt 3: Teilaufgabenliste in SubTaskList-Komponente

Schritt 4: Auslagerung in TaskView

Schritt 5: Aufgaben bearbeiten

Schritt 6: Integration in AppComponent

Datepicker

Kontextmenü verwenden

Nachfragen beim Löschen

Animationen

Sortieren der Aufgabenliste

Benutzeranmeldung

Hauptmenü

Testen

Auslieferung

26MiracleList-Electron-Client

Hybride Apps

Architektur von Electron

Electron-Projekt anlegen

Kommunikation zwischen Main und Renderer

Erweiterungen in der Webanwendung

Start der Electron-Anwendung

Debugging

Deployment

27MiracleList-Cordova-Client

Architektur von Cordova

Cordova-Projekt anlegen

Cordova-Anwendung starten

Erweiterungen in der Webanwendung

Cordova-APIs verwenden

Plug-ins verwenden

Responsive Web Design mit Bootstrap

Index

Vorwort zur 3. Auflage

Liebe Leserinnen und Leser,

herzlichen willkommen zur dritten, erheblich erweiterten Auflage dieses Buchs.

Warum dieses Buch?

Das Web hat sich verändert. Während für gute Webanwendungen vor rund zehn Jahren noch die Regel galt, so viele Aufgaben wie möglich auf dem Server zu erledigen (Server Side Rendering), wird heutzutage in vielen Fällen die Benutzeroberfläche auf dem Client gerendert (Client Side Rendering – CSR), sodass eine Single Page Application (SPA) entsteht. Der Webserver kommt oft nur noch für das initiale Laden der SPA und zum Datenaustausch via REST-Diensten (WebAPIs) zum Einsatz. Dank Basistechniken wie HTML5/CSS3, der erweiterten JavaScript-Syntax, und vielen neuen Browser-APIs sowie zahlreichen Frameworks, die die Handhabung einfacher machen, sind heutzutage Webanwendungen möglich, die in ihrer Benutzerfreundlichkeit Desktop-Anwendungen nahekommen.

Mittlerweile werden mit Webtechniken nicht nur Browseranwendungen, sondern auch mobile Apps und Desktop-Anwendungen entwickelt. Die Produktkombination aus HTML, CSS und JavaScript ist die einzige echte Cross-Platform-Technik, die die Entwicklung von Oberflächen für alle Betriebssysteme im Sinne von »Write once, run anywhere« ermöglicht.

Trotz des Trends zur Verlagerung des Renderings auf den Client gibt es weiterhin viele Webanwendungen, bei denen mit Server Side Rendering (SSR) gearbeitet wird.

Was ist der Inhalt dieses Buchs?

Dieses Buch beschreibt sowohl Server- als auch Clienttechniken für moderne Webanwendungen.

Anders als die Vorlagen beginnt das Buch mit einem Buchteil »Web-Basiswissen«, in dem HTTP, HTML und CSS besprochen werden. Diese Ergänzung findet bewusst statt, weil es Leser-Feedback zu den Vorauflagen gab, dass das Buch Vorwissen in diesen Bereichen voraussetzte. Natürlich kann hier nicht das komplette Wissen zu den Basistechniken des Webs abgedruckt werden. Die Basiskapitel von Jörg Krause geben Ihnen aber ein solides Fundament für den Rest des Buchs.

Serverseitig gab es im Jahr 2016 mit dem Erscheinen von ASP.NET Core einen erheblichen Umbruch, den allerdings viele Unternehmen technisch und/oder organisatorisch noch nicht nachvollziehen können. In diesem Buch wird daher auf der Serverseite sowohl das klassische ASP.NET (MVC, Web API, SignalR) im Buchteil B als auch das neue ASP.NET Core (inkl. MVC, Razor Pages und Web API, SignalR) im Buchteil C besprochen. Ein eigenes Kapitel widmet sich der Entwicklung von Microservices inklusive einer umfangreichen Fallstudie.

Im Buchteil D geht es dann um die Client-Programmierung mit JavaScript und TypeScript sowie die derzeit sehr weit verbreiteten Webframeworks Boostrap (von Twitter) und Angular (von Google). Informationen zu React (von Facebook) finden Sie in Kapitel 30, einem der drei Bonuskapitel, die Sie als Ergänzung des Buchs – so wie im Vorwort beschrieben – herunterladen können.

Ein ganz aktuelles Kapitel zu ASP.NET Blazor ergänzt diesen Buchteil. Auch wenn ASP.NET Blazor noch in einem früheren Entwicklungsstadium steckt, weckt es dennoch bei vielen .NET-Entwicklern die Hoffnung, zukünftig mit C# statt mit JavaScript/TypeScript SPAs im Browser programmieren zu können.

Buchteil E behandelt den Betrieb (das »Hosting«) von Webanwendungen in den Internet Information Services (IIS) von Windows, in Docker-Containern und in Microsoft Azure.

Das Buch beschließt den Buchteil F mit einem größeren Fallbeispiel: MiracleList ist eine moderne, auf Webtechniken basierende Cross-Platform-Anwendung zur Aufgabenverwaltung (in Anlehnung an www.wunderlist.com, für das Microsoft im Jahr 2015 einen dreistelligen Millionenbetrag bezahlt hat). Der Server basiert auf ASP.NET Core und läuft auf Windows, Linux oder macOS. Der Client basiert unter anderem auf HTML, CSS, JavaScript, Angular, Electron und Cordova. Er läuft daher sowohl im Browser als auch in Desktop-Anwendungen auf Windows, Linux oder macOS sowie als mobile App in iOS, Android und Windows Mobile.

Welche Voraussetzungen sollten Sie für dieses Buch mitbringen?

Das Buch richtet sich an Softwareentwickler, die bereits grundlegende Erfahrung mit .NET und C# besitzen und nun moderne Webanwendungen entwickeln wollen. Das Buch beinhaltet keine Einführung in .NET und C#, aber es führt in alle notwendigen Webtechniken ein.

Wenn Sie die Programmiersprache C# noch nicht oder noch nicht gut beherrschen, sollten Sie vorab dieses Buch lesen:

Holger Schwichtenberg:

C# 7.2 Crashkurs: Die Syntax der Programmiersprache C# für die Softwareentwicklung in .NET Framework, .NET Core und Xamarin.

www.IT-Visions.de, 2018

1. Auflage 2018167 Seiten, 15,00 €

ISBN: 978-3-93427-930-8

Was ist das Ziel des Buchs?

Zielsetzung dieses Buchs ist es, dem Leser zu zeigen, wie die Techniken eingesetzt werden können, um moderne Webanwendungen zu schaffen. Der Fokus liegt dabei auf den Konzepten, die hinter diesen Techniken stehen. Dazu spielt dieses Buch eine Vielzahl an Beispielen durch.

Es ist nicht Ziel dieses Buchs, ein Nachschlagewerk für die Vielzahl der Sprach- und Syntaxelemente sowie Klassen zu sein. Ein Nachschlagewerk zu all diesen Techniken würde viele Tausend Seiten dick sein. Schon bei der hier vorliegenden Seitenzahl mussten Inhalte gekürzt werden. Auf einige Fakten und Praxisbeispiele, die wir gerne präsentiert hätten, mussten wir daher leider verzichten.

Für eine erschöpfende Auflistung sämtlicher Befehle wird, gerade bei den clientseitigen Technologien, auf die umfangreichen frei verfügbaren Online-Referenzen verwiesen.

Darüber hinaus gehen wir auch davon aus, dass der Leser mit wenig Aufwand herausfinden kann, in welchem Namensraum beziehungsweise in welcher Assembly sich eine erwähnte Klasse befindet, sofern diese nicht ohnehin durch die in Visual Studio verwendeten Vorlagen eingebunden wurde.

Außerdem werden in diesem Buch keine Datenbankzugriffe besprochen. Hierzu sei auf das folgende Buch verwiesen:

Holger Schwichtenberg:

Effizienter Datenzugriff mit Entity Framework Core: Datenbankprogrammierung mit C# für .NET Framework, .NET Core und Xamarin.

Carl Hanser Verlag, 2018

468 Seiten, 42,00 €

ISBN: 978-3-446-44898-8

Welche Versionen werden in diesem Buch behandelt?

Das Buch behandelt die zum Redaktionsschluss des Buchs aktuellen stabilen Versionen. Dies sind unter anderem:

Visual Studio 2017 Version 15.6 und 15.7

Visual Studio Code 1.22

.NET Framework 4.7.2

.NET Core 2.0.2 (mit Ausblick auf die Version 2.1)

ASP.NET MVC 5.2.4

ASP.NET Web API 5.2.4

ASP.NET Core 2.0.2 (mit Ausblick auf die Version 2.1)

Bootstrap 4.0.0

TypeScript 2.8.1

Angular 5.2.9

React 16.2.0

Internet Information Services 10.0

Docker 18.05.0

Electron 1.8.3

Cordova 8.0

Welche Programmiersprache wird in diesem Buch verwendet?

Das vorliegende Buch verwendet serverseitig die Programmiersprache C# sowie clientseitig JavaScript und TypeScript.

Alle Leser, die serverseitig lieber mit Visual Basic .NET arbeiten, können die abgedruckten Beispiele sehr einfach mit kostenlosen Werkzeugen nach Visual Basic .NET konvertieren. Informationen dazu findet man unter http://www.dotnetframework.de/tools.aspx.

Welche Werkzeuge werden in diesem Buch verwendet?

Dieses Buch bezieht sich primär auf die Programmierung mit der integrierten Entwicklungsumgebung Visual Studio. Von Visual Studio kann man eine kostenfreie Community Edition nur in kleineren Firmen und bei Open-Source-Projekten kostenfrei einsetzen (www.visualstudio.com/vs/community). Für die Webclient-Programmierung kommt auch Visual Studio Code (https://code.visualstudio.com) zum Einsatz. Zudem sollten Sie node.js (nodejs.org) installieren, um den Node Package Manager (NPM) zur Verfügung zu haben. Für das Testen von Web APIs wird Postman (www.getpostman.com) und Fiddler (www.telerik.com/download/fiddler) verwendet. Auf weitere Werkzeuge wird in den einzelnen Kapiteln hingewiesen.

Welche Sprachversion wird in diesem Buch verwendet?

Dieses Buch beschreibt die englische Version von Visual Studio, weil inzwischen viele deutsche Entwickler (einschließlich der Autoren) die englische Version der Software bevorzugen, denn die Übersetzungen ins Deutsche sind oft holprig und die Fehlermeldungen nur schwer verständlich. Visual-Studio-Anwender können über den Befehl Tools/Options/Environment/International Settings weitere Sprachpakete herunterladen und einrichten. Weiterhin sei noch darauf hingewiesen, dass die Anordnung der Menüs und auch einige Tastaturkürzel von den gewählten Einstellungen in Visual Studio abhängen. Alle Ausführungen in diesem Buch beziehen sich auf die Umgebungseinstellung Common Settings, die bei der Installation des Produkts ausgewählt werden kann.

Woher bekommen Sie die Code-Beispiele und die drei Bonuskapitel zu diesem Buch?

Die Code-Beispiele zu diesem Buch erhalten Sie auf oreilly.de auf der Webseite zum Buch Moderne Webanwendungen für .NET-Entwickler unter »Zusatzmaterial«.

Hier finden Sie außerdem drei zusätzliche Kapitel als PDF zum Download, die dieses Buch inhaltlich abrunden: Kapitel 28 »Open Web Interface for .NET (OWIN) und Katana«, Kapitel 29 »Sicherheit in ASP.NET« sowie Kapitel 30 »React«.

Die Autoren bieten den Leserinnen und Lesern dieses Buchs darüber hinaus im Rahmen einer zugangsbeschränkten Website folgende Serviceleistungen:

Bonuskapitel

Ergänzend erhalten Sie auch hier die drei zusätzlichen Kapitel als PDF zum Download: Kapitel 28 »Open Web Interface for .NET (OWIN) und Katana«, Kapitel 29 »Sicherheit in ASP.NET« sowie Kapitel 30 »React«.

Downloads

Sie können alle in diesem Buch vorgestellten Code-Beispiele hier herunterladen.

Spickzettel (Cheat Sheets)

Ergänzend erhalten Sie hier drei Spickzettel in PDF-Form mit den wichtigsten Befehlen von ASP.NET (Core) MVC und Web API, TypeScript und Angular – zum Ausdrucken und »Spicken« beim Programmieren.

Diskussionsrunde

Ein webbasiertes Forum bietet die Möglichkeit, Fragen an die Autoren zu stellen. Bitte beachten Sie jedoch, dass dies eine freiwillige Leistung der Autoren ist und kein Anspruch auf eine kostenlose Betreuung besteht.

Newsletter

Alle registrierten Leser erhalten zwei- bis viermal jährlich einen Newsletter mit aktuellen Terminen und Publikationshinweisen.

Leserbewertung

Vergeben Sie Noten für dieses Buch und lesen Sie nach, was andere Leser von diesem Buch halten.

Errata

Trotz eines jahrelang erprobten Vorgehensmodells und der dreifachen Qualitätskontrolle (Co-Autor, Fachlektor, Verlag) ist es möglich, dass sich einzelne Fehler in dieses Buch eingeschlichen haben. Im Webportal können Sie nachlesen, welche Fehler gefunden wurden. Sie können hier auch selbst Fehler, die Ihnen auffallen, melden.

Abbildung V.1: Der Spickzettel zu ASP.NET (Core) MVC und Web API

Zugang zu der ehrenamtlich betriebenen Leser-Website erhalten Sie unter www.IT-Visions.de/Leser. Dort müssen Sie sich einmalig registrieren. Bei der Registrierung wird ein Losungswort abgefragt, das Sie als Käufer dieses Buchs ausweist. Bitte geben Sie dort Beyond ein. Durch die Registrierung erhalten Sie ein persönliches Kennwort per E-Mail zugesendet, das Sie dann für die Anmeldung nutzen können.

Dieses Symbol weist auf eine Warnung oder ein Problem hin.

Dieses Symbol markiert einen allgemeinen Hinweis oder Tipp.

Wem ist zu danken?

Für ihre Mitwirkung an diesem Buch möchte ich danken:

meinem Co-Autor Jörg Krause, der den Großteil des Texts im Buchteil »Web-Basiswissen« sowie die Kapitel zu JavaScript, Bootstrap und React geschrieben hat.

meinem ehemaligen Co-Autor Manfred Steyer, der sich nun leider nicht mehr mit den Themen dieses Buchs beschäftigt, von dem wir aber einige Texte zum klassischen ASP.NET MVC und Web API in die neue Auflage übernehmen durften.

Dr. Joachim Fuchs für das Kapitel »ASP.NET Core SignalR«.

Sebastian Kleinschmager für die Kapitel zu ASP.NET Core Web APIs und Microservices.

der O’Reilly-Lektorin Ariane Hesse.

der Korrektorin Claudia Lötschert, die das Buch sprachlich verbessert hat.

Essen im Herzen des Ruhrgebiets, im April 2018

Holger Schwichtenberg

Die Autoren

Über www.IT-Visions.de

Alle Autoren dieses Buchs arbeiten bei der Firma www.IT-Visions.de als Softwarearchitekten, Softwareentwickler, Trainer und Berater für .NET-Techniken. www.IT-Visions.de ist ein Verbund der deutschen Top-Experten im Bereich der Microsoft-Produkte und -Technologien insbesondere .NET. Unter Leitung und Mitwirkung von Dr. Holger Schwichtenberg bietet www.IT-Visions.de:

Strategische und technische Beratung

Konzepte, Machbarkeitsstudien und Reviews

Coaching bei Entwicklungsprojekten

Technischen Support vor Ort und via Telefon, E-Mail oder Web-Konferenz

Individuell zugeschnittene technische Vor-Ort-Schulungen und anforderungsorientierte Workshops

Öffentliche Seminare, siehe

www.dotnet-akademie.de

Die Schwestergesellschaft 5Minds IT-Solutions GmbH & Co. KG bietet Softwareentwicklung (Prototypen und komplette Lösungen) sowie den Verleih von Softwareentwicklern.

Zu den Kunden gehören neben vielen mittelständischen Unternehmen auch Großunternehmen wie z.B. Siemens, Bayer, RWE, Bertelsmann, BASF, Bosch, Thyssen-Krupp, Merkle, Festo, Lufthansa, AIRBUS, REWE, EnBW, DEA, PwC, Deutsche Telekom, Deutsche Post, Karstadt, eurofins, Roche, OSRAM, Jenoptik, Continental, Carl Zeiss, Haufe-Lexware, TÜV, Sartorius, Fraunhofer, diverse Banken und Versicherungen sowie mehrere Landesregierungen.

Firmenwebsites:

http://www.IT-Visions.de

und

http://www.5minds.de

Kontakt zu allen Autoren: E-Mail

[email protected]

sowie Telefon

0201-64 95 90-0

Dr. Holger Schwichtenberg

Studienabschluss Diplom-Wirtschaftsinformatik an der Universität Essen

Promotion an der Universität Essen im Gebiet komponentenbasierter Softwareentwicklung

Seit 1996 selbstständig als unabhängiger Berater, Dozent, Softwarearchitekt und Fachjournalist

Leiter des Berater- und Dozententeams bei

www.IT-Visions.de

Softwareentwicklungsprojektleitung im Bereich Microsoft/.NET bei der 5minds IT-Solutions GmbH & Co. KG (

www.5minds.de

)

Über 65 Fachbücher beim Carl Hanser Verlag, bei O’Reilly, Microsoft Press und Addison-Wesley sowie mehr als 1000 Beiträge in Fachzeitschriften

Gutachter in den Wettbewerbsverfahren der EU gegen Microsoft (2006–2009)

Ständiger Mitarbeiter der Zeitschriften iX (seit 1999), dotnetpro (seit 2000) und Windows Developer (seit 2010) sowie beim Onlineportal heise.de (seit 2008)

Regelmäßiger Sprecher auf nationalen und internationalen Fachkonferenzen (zum Beispiel Microsoft TechEd, Microsoft Summit, Microsoft IT Forum, BASTA, BASTA-on-Tour, .NET Architecture Camp, Advanced Developers Conference, Developer Week, OOP, DOTNET Cologne, MD DevDays, Community in Motion, DOTNET-Konferenz, VS One, NRW.Conf, Net.Object Days, Windows Forum, Container Conf)

Zertifikate und Auszeichnungen von Microsoft:

– Microsoft Most Valuable Professional (MVP)

– Microsoft Certified Solution Developer (MCSD)

Thematische Schwerpunkte:

– Softwarearchitektur, mehrschichtige Softwareentwicklung, Softwarekomponenten, SOA

– Microsoft .NET Framework, Visual Studio, C#, Visual Basic

– .NET-Architektur/Auswahl von .NET-Technologien

– Einführung von .NET Framework und Visual Studio/Migration auf .NET

– Webanwendungsentwicklung und Cross-Plattform-Anwendungen mit HTML, ASP.NET, JavaScript/TypeScript und Webframeworks wie Angular

– Enterprise .NET, verteilte Systeme/Webservices mit .NET, insbesondere Windows Communication Foundation und Web API

– Relationale Datenbanken, XML, Datenzugriffsstrategien

– Objektrelationales Mapping (ORM), insbesondere ADO.NET Entity Framework und EF Core

– Windows PowerShell, PowerShell Core und Windows Management Instrumentation (WMI)

Jörg Krause

Jörg Krause arbeitet seit vielen Jahren als Autor, Trainer, Berater und Softwareentwickler für große Unternehmen weltweit. Bauen Sie auf die Erfahrung aus mehr als 25 Jahren Arbeit mit Webumgebungen und sehr vielen großen und kleinen Projekten. Schwerpunkte der Arbeit sind Webtechnologien und damit verwandte Bereiche. Dies umfasste sowohl den Frontend- als auch den Backend-Bereich sowie Nutzung von Windows und auch von Linux mit der Wahl der jeweils optimalen Plattform.

Er hat über 40 Titel bei renommierten Fachverlagen in Deutsch und Englisch veröffentlicht, darunter auch einige Bestseller. Weitere Titel sind im Eigenverlag erschienen, ebenso wie zahlreiche Zeitschriftenartikel. Sein Wissen gibt er in Seminaren und Schulungen und gelegentlich auf Fachkonferenzen weiter. Zu den Grundlagenthemen gehören HTML, CSS, JavaScript und TypeScript, aktuelle Anwendungs-Rahmenwerke wie React und Angular sowie Backend-Technologien wie beispielsweise SQL Server, Node.js, ASP.NET und Docker.

Jörg sind vor allem solide Grundlagen wichtig. Statt immer dem neuesten Framework hinterherzurennen wären viele Entwickler besser beraten, sich eine robuste Grundlage zu schaffen. Wer dies kompakt und schnell lernen will, ist bei ihm richtig. Deshalb wird der didaktischen Aufbereitung in seinen Schulungen und Veröffentlichungen besondere Aufmerksamkeit zuteil.

Dr. Joachim Fuchs

Dr.-Ing. Joachim Fuchs ist ein bekannter Experte für .NET mit Schwerpunkt auf UI-Techniken (insbesondere WPF, ASP.NET MVC und Angular). Er arbeitet für www.IT-Visions.de als Trainer und Softwareentwickler. Durch seine Fachbücher und Artikel in Fachzeitschriften ist er in der .NET-Szene bestens bekannt.

Sebastian Kleinschmager

Sebastian Kleinschmager ist freiberuflicher Softwareentwickler und Trainer. Seine technologischen Schwerpunkte liegen im Bereich .NET/C# und Webtechnologien, vor allem ASP.NET Core und Angular. Zudem beschäftigt er sich stark mit den Themen Clean Code, Qualitätssicherung und Architektur, dort insbesondere Microservices und ähnlichen Ansätzen. Sein Wissen zu diesen Themen bringt er mit viel Leidenschaft bei seinen Kunden in Projekte ein und vermittelt es genauso motiviert als Dozent und Teil des www.IT-Visions.de-Expertenteams.

Manfred Steyer

Manfred Steyer ist Trainer und Berater bei www.IT-Visions.de sowie verantwortlich für den Fachbereich Software Engineering der Studienrichtung IT und Wirtschaftsinformatik an der FH CAMPUS 02 in Graz.

Er schreibt für das windows.developer magazin (vormals dot.net magazin) sowie Heise Developer und ist Buchautor bei O’Reilly, Microsoft Press sowie Carl Hanser. Manfred hat berufsbegleitend IT und IT-Marketing in Graz sowie Computer Science in Hagen studiert und kann auf mehr als 15 Jahre an Erfahrung in der Planung und Umsetzung von großen Applikationen zurückblicken. Er ist ausgebildeter Trainer für den Bereich der Erwachsenenbildung und spricht regelmäßig auf Fachkonferenzen.

In der Vergangenheit war Manfred Steyer mehrere Jahre für ein großes österreichisches Systemhaus tätig. In der Rolle als Bereichsleiter hat er gemeinsam mit seinem Team Geschäftsanwendungen konzipiert und umgesetzt.

TEIL A

Web-Basiswissen

Kapitel 1Protokolle, Standards und Konzepte

Kapitel 2Hypertext Markup Language (HTML)

Kapitel 3Cascading Style Sheets (CSS)

Kapitel 4Bootstrap

Dieses Buchkapitel vermittelt Basiswissen im Bereich der Webtechniken, die die Grundlage sowohl für die Server- als auch Clientprogrammierung bilden. Zudem wird in diesem Buchteil auch Bootstrap besprochen, das von CSS abstrahiert. Wir besprechen Bootstrap bereits in diesem Teil, weil Microsoft es in den Projektvorlagen für ASP.NET und ASP.NET Core einsetzt.

KAPITEL 1

Protokolle, Standards und Konzepte

Dieses Kapitel bietet einen sehr kompakten Überblick über die Protokolle, die Sie kennen sollten, wenn Sie aktiv Webanwendungen entwickeln möchten.

Standardisierung

Dieses Kapitel erwähnt kurz die drei wichtigsten Standardisierungsgremien für die Webprogrammierung.

RFCs

Wenn Sie sich mit Protokollen und konkreten Implementierungen technischer Verfahren rund um das Internet beschäftigen, werden Sie immer wieder mit RFCs (Request for Comments) (www.elektronik-kompendium.de/sites/net/0904121.htm) konfrontiert. Die RFCs dienen als öffentliches Diskussionsforum für technische und organisatorische Fragen des Internets. Sie wurden mit dem ARPA-NET im Jahre 1969 ins Leben gerufen. Die RFC 0001 wurde am 7. April 1969 veröffentlicht, noch während der laufenden Entwicklung des ARPANET (de.wikipedia.org/wiki/Arpanet).

RFCs werden fortlaufend nummeriert und können verschiedene Stufen durchlaufen. Es gibt keine Versionsnummern. Wird ein RFC umfassend weiterentwickelt, erscheint ein neues Dokument mit einer neuen Nummer. Das alte wird als obsolet gekennzeichnet. Werden aus RFCs Standards verabschiedet, so erscheinen diese in einer zweiten Dokumentform, die durch STD gekennzeichnet ist. Der Zusammenhang zwischen RFCs und STDs ist in RFC 2500 geregelt. Der Standardisierungsprozess wird in RFC 2026 erläutert.

Als gute Informationsquelle für RFCs ist die Webseite www.rfc-editor.org zu empfehlen. Hier können Sie in der RFC- und STD-Datenbank komfortabel stöbern. Wenn Sie nach tiefer gehenden Informationen zu bestimmten Protokollen wie beispielsweise ICMP oder DNS suchen, tragen Sie diese in die Suchmaske ein.

Abbildung 1-1: Eine gute Informationsquelle ist der RFC-Editor.

Amüsant kann das Studium von RFCs mit dem Erscheinungsdatum vom 1. April und dem Status INFORMATIONAL sein. Zu empfehlen ist hier beispielsweise RFC 2550, in dem die Jahr-10.000-Problematik erörtert wird.

World Wide Web Consortium (W3C)

Neben den RFCs sind die Standards des seit dem Jahr 1994 tätigen World Wide Web Consortium (W3C) die wichtigsten Standards im Web. Das W3C hat unter anderem HTML, XHTML und XML standardisiert.

European Computer Manufacturers Association (ECMA)

Die ECMA standardisiert JavaScript unter seinem offiziellen Namen ECMAScript. Auch die Programmiersprachen C# und C++/CLI sind hier standardisiert.

Hypertext Transfer Protocol (HTTP)

In diesem Abschnitt erfahren Sie das Wichtigste über HTTP, das in der Webserver-Programmierung eine herausragende Rolle spielt.

HTTP dient der Kommunikation mit Webservern. Es gibt die Versionen 1.0 (1996, RFC 1945), 1.1 (1999, RFC 2616) und 2.0 (2015, RFC 7540). Aufseiten der Browser wird von HTTP 1.1 gesprochen, einige neuere (Chrome, Edge) kennen bereits HTTP 2.0. Die Version 2.0 befindet sich heute (2017) in der Einführungsphase. Dazu kommt eine Reihe von Sub-Standards, die teilweise implizit benutzt werden:

RFC 7541 Header Compression (2, 2015)

RFC 7230 Message Syntax and Routing (1.1, 2014)

RFC 7231 Semantics and Content (1.1, 2014)

RFC 7232 Conditional Requests (1.1, 2014)

RFC 7233 Range Requests (1.1, 2014)

RFC 7234 Caching (1.1, 2014)

RFC 7235 Authentication (1.1, 2014)

Bei HTTP handelt es sich um ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand ein, sondern beenden nach jedem Kommando den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren.

Einer der großen Vorteile von HTTP als dem Protokoll der Wahl für die Kommunikation im Web und auch für Inter-Service-Kommunikation ist seine Einfachheit. HTTP setzt auf TCP/IP als etabliertes Transportprotokoll auf und kommt ohne eigenen schwergewichtigen Protokollrahmen und Metadaten aus. Egal ob auf mobilen Geräten, in Webbrowsern oder bei Cloud-Services, egal ob auf der Java-Plattform, unter PHP oder .NET: HTTP wird überall unterstützt. Dies ist auch der Grund dafür, dass REST-Web-API-Services (alias »HTTP Services«) auf dem Vormarsch sind, die direkt auf HTTP basieren und auf aufwendige aus der Welt der verteilten Programmierung bekannte Protokolle wie SOAP verzichten.

Protokollaufbau, Header, Body

HTTP-Kommandos werden als ASCII-Text übertragen und können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Kommandozeile. Daran angehängt kann ein Message-Header (Nachrichtenkopf) folgen. Der Nachrichtenkopf enthält weitere Kopffelder, die das Kommando näher beschreiben. So ist in der Regel immer ein Content-Length-Kopffeld enthalten. Steht dort ein Wert größer als 0, folgen dem Nachrichtenkopf Daten. Die Daten werden also gleich zusammen mit dem Kommando gesendet, man spricht dann vom Body (Körper) der Nachricht. HTTP versteht im Gegensatz zu anderen Protokollen den Umgang mit 8-Bit-Werten. Binärdaten, wie Bilder oder Sounds, müssen nicht konvertiert werden. Folgen dem HTTP-Kommando und den Nachrichtenkopf-Zeilen zwei Leerzeilen (Zeilenwechsel), so gilt das Kommando als beendet. Kommandos mit Nachrichtenkörper haben kein spezielles Ende-Zeichen. Das Content-Length-Kopffeld bestimmt, wie viele Bytes als Inhalt der Nachricht betrachtet werden.

Kommandoaufbau

Ein HTTP-Kommando hat immer folgenden Aufbau:

1 METHODE ID VERSION

Als METHODE wird das Kommando selbst bezeichnet.

Methode oder Verb?

In der Literatur wird die HTTP-Methode manchmal als »Verb« bezeichnet. Der Begriff Verb kommt jedoch in der RFC und allen Standardisierungsdokumenten nicht vor. Die Ursache liegt in der Bezeichnung einiger Klassen und Datentypen in den Entwicklungsumgebungen von Microsoft (technet.microsoft.com/de-de/library/dd569062.aspx), wo Methoden als HTTP-Verben bezeichnet werden (siehe technet.microsoft.com/de-de/library/dd569062.aspx).

Die folgende Tabelle zeigt die wichtigsten HTTP-Methoden auf einen Blick.

Tabelle 1-1: Auswahl HTTP-Methoden

Methode

Bedeutung

CONNECT

Verbindung zu einer TLS-Ressource aufbauen

DELETE

Ressource löschen (siehe Kapitel zu REST)

GET

Ressource anfordern

HEAD

Header der Ressource anfordern

LINK

Verknüpfung zweier Ressourcen beantragen

OPTIONS

Merkmale des Webservers erfragen, Auth-Preflight

POST

Formulardaten an einen Serverprozess senden

PUT

Ressource auf dem Webserver ablegen (siehe Kapitel zu REST)

TRACE

Kommando zurückschicken lassen

UNLINK

Verknüpfung zwischen Ressourcen löschen

Beachten Sie hier, dass die Methode unbedingt in Großbuchstaben geschrieben werden muss, exakt wie in der Tabelle oben gezeigt.

Die Standardmethoden verwenden Großbuchstaben, was bei anderen Methoden für spezielle Zwecke nicht zwingend so ist. Deshalb ist die Unterscheidung wichtig, weil »Delete« eben etwas völlig anderes bedeuten kann als »DELETE«.

Als Ressource werden all die Objekte bezeichnet, die übertragen werden können – in erster Linie also HTML-Dateien, Daten und Bilder.

Die ID einer Ressource kann beispielsweise eine Adresse oder ein Dateiname sein:

1 GET index.html HTTP/1.0

Dieses Kommando fordert die Datei index.html an.

Die HTTP-Statuscodes

Die Antwort auf ein Kommando besteht im Senden der Daten – wenn dies gefordert wurde – und einem Statuscode. Dem Statuscode folgen optionale Felder und, bei der Übertragung von Ressourcen, die Daten. Die Statuszeile hat folgenden Aufbau:

1 VERSION STATUSCODE STATUSTEXT

Der Statuscode ist eine dreistellige Zahl, von der die erste Ziffer (Hunderterstelle) die Zuordnung zu einer bestimmten Gruppe anzeigt.

Tabelle 1-2: HTTP-Antwortcodes (Auswahl)

Sicher kennen Sie den Fehler 404. Man geht davon aus, dass der Fehler beim Client liegt (Gruppe 4), also schlicht die falsche Ressource angefordert wurde. Sie werden schnell den Fehler 500 kennenlernen, der erzeugt wird, wenn ein Programm nicht funktioniert. Das Programm läuft auf dem Server, und deshalb ist es ein Fehler der Gruppe 5.

Ablauf einer HTTP-Kommunikation

Der grundsätzliche Ablauf einer HTTP-Kommunikation besteht aus zwei Teilen, nämlich Anfrage (request) und Antwort (response). Dies sieht beispielsweise folgendermaßen aus:

Listing 1-1: Anfrage

1 GET http://www.it-visions.de/ HTTP/1.1

2 Accept: text/html, application/xhtml+xml, image/jxr, */*

3 Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3

4 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; LCJB; \

5 rv:11.0) like Gecko

6 Accept-Encoding: gzip, deflate

7 Host: www.it-visions.de

8 Connection: Keep-Alive

Listing 1-2: Antwort (nur Kopffelder, ohne Daten)

1 HTTP/1.1 200 OK

2 Date: Sun, 17 Jan 2016 10:59:09 GMT

3 Server: Apache

4 X-Powered-By: PHP/5.5.30

5 Expires: Thu, 19 Nov 1981 08:52:00 GMT

6 Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pr\

7 e-check=0

8 Pragma: no-cache

9 X-Pingback: http://www.it-visions.de/xmlrpc.php

10 Link: <http://wp.me/P6sMv6-12>; rel=shortlink

11 Set-Cookie: PHPSESSID=4744597c154b01a61e245292b8f1a897; path=/

12 Keep-Alive: timeout=2, max=200

13 Connection: Keep-Alive

14 Content-Type: text/html; charset=UTF-8

15 Content-Length: 27465

Kopffelder

An ein Kommando oder an die Statuszeile können weitere Felder angehängt werden, sogenannte Kopffelder (manchmal auch Kopfzeilen genannt, weil jedes Feld auf einer Zeile steht) oder kurz Header:

Feldname: Wert; Wert

Die Nachrichtenkopffelder können in drei Hauptgruppen aufgeteilt werden:

F: Fragefelder (Request-Header-Fields), die nur in Kommandos erlaubt sind.

A: Antwortfelder (Response-Header-Fields), die Statusnachrichten vorbehalten sind.

I: Informationsfelder (General-Header-Fields), sie dienen der Übertragung aller anderen Nachrichten in die eine oder andere Richtung.

Eine typische Anwendung, die bei der Webprogrammierung auftreten kann, ist die Übergabe eines Nachrichtenkopffelds, das einen besonderen Dateityp für das Herunterladen einer Datei angibt:

Content-Type: application/pdf; name=aspnet.pdf

Im Gegensatz zu anderen Protokollen ist die Länge eines Datenblocks im Content-Length-Kopffeld festgelegt, irgendwelche Begrenzungszeichen gibt es nicht. Wichtig ist auch, dass der Server nach dem Verbindungsaufbau keine Antwort sendet. Nur das erste eintreffende Kommando löst eine Reaktion aus. Darin ist die Ursache zu sehen, wenn der Browser nach der Anforderung eines unerreichbaren Servers lange Zeit nicht reagiert. Als »Totsignal« wird einfach eine vorgegebene Zeitspanne gewartet, in der der Server auf das erste Kommando reagieren sollte.

HTTP 2.0

Die aktuelle Version von HTTP ist HTTP 2.0 (im Header als HTTP/2 bezeichnet), die als RFC 7540 am 15. Mai 2015 veröffentlicht wurde.

Der Standard ist heute in den RFC 7540 und 7541 spezifiziert. Die Entwicklung war maßgeblich von Google (SPDY, spricht man aus wie »speedy«) und Microsoft (HTTP Speed+Mobility) mit jeweils eigenen Vorschlägen vorangetrieben worden. Ein erster Entwurf, der sich weitgehend an SPDY anlehnte, war im November 2012 publiziert und seither in mehreren Schritten angepasst worden.

Mit HTTP/2 soll die Übertragung beschleunigt und optimiert werden. Der neue Standard ist vollständig abwärtskompatibel zu HTTP/1.1.

Wichtige neue Möglichkeiten sind:

das Zusammenfassen mehrerer Anfragen

bessere Kompressionsmöglichkeiten

binär codierte Übertragung von Inhalten

Server-initiierte Datenübertragungen (Push-Verfahren)

Eine Beschleunigung ergibt sich hauptsächlich aus der neuen Möglichkeit des Zusammenfassens (Multiplex) mehrerer Anfragen, um sie über eine Verbindung abwickeln zu können. Die Datenkompression kann nun auch Kopfdaten mit einschließen. Statt des bisher benutzten Gzip oder Deflate erreicht man dies mit dem neuem Spezialalgorithmus namens HPACK (tools.ietf.org/html/rfc7541) (RFC 7541).

Inhalte können binär codiert übertragen werden. Um nicht auf serverseitig vorhersehbare Folgeanforderungen vom Client warten zu müssen, können Datenübertragungen teilweise vom Server initiiert werden (Push-Verfahren).

Die ursprünglich geplante Option, dass HTTP/2 standardmäßig TLS (Transport Layer Security, früher SSL genannt, dient der Verschlüsselung) nutzt, wurde nicht umgesetzt. Allerdings kündigten Google und Mozilla für ihre Browser an, dass diese HTTP/2 nicht ohne Verschlüsselung unterstützen werden (siehe Application-Layer Protocol Negotiation (de.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)). Aufgrund der Marktmacht muss man davon ausgehen, dass damit alle HTTP/2-Server zwingend TLS anbieten müssen.

Die verbreiteten modernen Browser unterstützen inzwischen HTTP/2. Darunter Google Chrome (auch unter iOS und Android) ab Version 41, Mozilla Firefox ab Version 36, Internet Explorer 11 und Edge unter Windows 10, Opera ab Version 28 (auch Opera Mobile ab Version 24) und Safari ab Version 8.

Ergänzende Standards zu HTTP

Flankiert wird HTTP durch weitere Standards, die entweder darauf aufsetzen oder ergänzend benutzt werden.

Web-Sockets

Das Web-Socket-Protokoll (de.wikipedia.org/wiki/Web-Socket) ist ein auf TCP basierendes Netzwerkprotokoll, das entworfen wurde, um eine bidirektionale Verbindung zwischen einer Webanwendung und einem Web-Socket-Server beziehungsweise einem Webserver, der auch Web-Sockets unterstützt, herzustellen. Es entfallen bei Web-Sockets die durch die HTTP-Kopffelder verursachten zusätzlichen Daten.

Während bei einer reinen HTTP-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, muss beim Web-Socket-Protokoll der Client die Verbindung nur eröffnen. Der Server kann dann diese offene Verbindung aktiv verwenden und weitere Informationen an den Client senden, ohne auf eine neue Verbindung des Clients zu warten.

Die Anfrage wird mit einem speziellen Kopffeld aus HTTP heraus initiiert:

1 GET /chat HTTP/1.1

2 Host: server.example.com

3 Upgrade: websocket

4 Connection: Upgrade

6 Origin: http://example.com

7 Sec-Web-Socket-Protocol: chat, superchat

8 Sec-Web-Socket-Version: 13

Die Antwort sollte dann den Statuscode 101 enthalten:

1 HTTP/1.1 101 Switching Protocols

2 Upgrade: websocket

3 Connection: Upgrade

5 Sec-Web-Socket-Protocol: chat

Durch den HTTP-Statuscode 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist.

Technisch betrachtet startet bei Web-Socket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrunde liegende TCP-Verbindung bestehen bleibt und Übertragungen in beide Richtungen ermöglicht.

WebDAV

WebDAV (de.wikipedia.org/wiki/WebDAV) (Web-based Distributed Authoring and Versioning) ist ein offener Standard zur Bereitstellung von Dateien im Internet. Dabei können Benutzer auf ihre Daten transparent zugreifen, also schreibend und lesend.

Technisch gesehen ist WebDAV eine Erweiterung des Protokolls HTTP/1.1, die bestimmte Einschränkungen von HTTP aufhebt. Mit WebDAV können Dateien und auch ganze Verzeichnisse übertragen werden. Zudem ist eine Versionskontrolle spezifiziert.

Da der schreibende Zugriff auf Webserver ziemlich riskant ist, hat WebDAV keine massive Verbreitung gefunden. Es wird, wenn überhaupt, zum Veröffentlichen von Anwendungen aus einer lokalen Entwicklungsumgebung heraus benutzt. Einige Webhoster und Provider bieten dies als leistungsfähige Alternative zu FTP an.

Simple Mail Transfer Protocol (SMTP) oder Extended SMTP (ESMTP)

SMTP kommt in Clientsystemen für das Versenden sowie bei Mailservern zum Senden und Weiterleiten von E-Mails zum Einsatz. Inzwischen hat sich der ESMTP-Standard durchgesetzt. Dieser ist in RFC 2821 spezifiziert und bietet erweiterte Funktionen zur Kommunikation zwischen SMTP-Client und -Server.

Wie viele Protokolle im Webumfeld ist auch dieses Protokoll ASCII-Text-basiert. Alle Nachrichten, die vom Client zum Server gesendet werden, können dabei sowohl vom Menschen als auch von der Software interpretiert werden.

File Transfer Protocol (FTP)

Neben HTTP ist FTP das wichtigste Protokoll beim tagtäglichen Einsatz im Internet. Es dient dem Datenaustausch zwischen FTP-Server und -Client, wobei der Client auf eine genau definierte Art und Weise Zugriff auf das Dateisystem des Servers erhalten kann.

Für den Zugriff auf einen FTP-Server bieten alle modernen Betriebssysteme verschiedene Arten von Clients. Dazu kommen viele grafische FTP-Clients.

REpresentational State Transfer (REST)

REST steht für REpresentational State Transfer und bezeichnet einen Architekturstil (oder auch ein »Programmierparadigma für verteilte Systeme«, siehe dazu auch de.wikipedia.org/wiki/Representational_State_Transfer), der bereits häufig benutzte Techniken und Protokolle zusammenfasst und für die Datenübertragung nutzt. Dies umfasst:

URI für die Adressierung von Ressourcen

HTTP für Übertragung von Kommandos

MIME für die Codierung der Ressourcen

JSON oder XML für die Formatierung

Webdienste

REST ist eine spezielle Form eines Webdiensts (Webservice). Man spricht deshalb auch von einem REST-Dienst.

Merkmale

Die technischen Merkmale eines REST-Diensts sind:

Adressierbarkeit

Repräsentationsvariabilität

Zustandslosigkeit

Skalierbarkeit

Allgemeingültigkeit

Erweiterbarkeit

Adressierbarkeit

Jeder REST-konforme Dienst hat eine eindeutige Adresse, den Uniform Resource Locator (URL). Zusätzlich zum URL, der den Dienst selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.

Repräsentationsvariabilität

Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann beispielsweise HTML, JSON oder XML liefern. Dies können Daten oder Beschreibungen von Daten sein (Metadaten).

Zustandslosigkeit

Jede REST-Nachricht enthält alle Informationen, die für den Server beziehungsweise Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (stateless) Protokoll. Jede Anfrage eines Clients beinhaltet sämtliche Informationen über den Anwendungszustand, die vom Server benötigt werden.

Skalierbarkeit

Die Zustandslosigkeit begünstigt die Skalierbarkeit eines Diensts. Da jede Anfrage zu einer definierten Reaktion führt und keine Voraussetzungen auf einer bestimmten Maschine vorhanden sein müssen, können Lastverteiler Anfragen auf mehrere Maschinen verteilen, ohne dass dies Änderungen an der serverseitigen Verarbeitung nach sich zieht.

Allgemeingültigkeit

HTTP schreibt vor, dass GET »sicher« (safe) sein muss. Dies bedeutet, dass diese Methode nur Informationen beschafft und keine Nebeneffekte hat. Die Methoden GET, HEAD, PUT und DELETE müssen idempotent (nebeneffektfrei) sein, was bedeutet, dass sich das mehrfache Absenden der gleichen Anforderung nicht anders auswirkt als ein einzelner Aufruf.

Erweiterbarkeit

Erweiterbarkeit heißt, dass sich später erfolgende Erweiterungen der Ressourcenbasis, zusätzliche Funktionen, mehr Daten, anderen Repräsentationen oder Skalierungsmaßnahmen nicht auf die bestehenden Clients auswirken dürfen.

REST-Beispiel

Ein Merkmal von REST ist die Beschreibung von Ressourcen. Dazu gehören Links zu weiterführenden Elementen. Bestehen zwischen Daten Beziehungen, so ist dies in der Antwort zu erkennen. Eine einfache Abfrage nutzt das Kommando GET, also zum Beispiel GET /book/2605.

1 HTTP/1.1 200 OK Content-Type: text/xml

2 <?xml version="1.0"?>

3 <book xmlns:xlink="http://www.w3.org/1999/xlink">

4 <cat xlink:href="http://shop.meinefirma.de/cat/122">122</cat>

5 <author xlink:href="http://shop.meinefirma.de/author/1">1</author>

6 <author xlink:href="http://shop.meinefirma.de/author/2">2</author>

7 <title>JADE</title>

8 <desc>Die Template-Engine JADE</desc>

9 <price>2,99</price>

10 <type>Paperback</type>

11 </book>

Hier verweisen die URIs einiger Elemente auf abhängige Ressourcen. Der Client kann dies nutzen, um einen Teil der Benutzeroberfläche dynamisch zu erstellen.

URI

URI steht für Uniform Resource Identifier und ist das Verfahren zum Konstruieren der Adressen. Im Zusammenhang mit REST ist oft der Begriff RESTful zu sehen. Es ist wichtig zu verstehen, dass damit die korrekte Implementierung von REST gemeint ist. Das heißt nicht, dass lediglich HTTP benutzt wird, sondern auch, dass die Routen, die zum Abruf von Daten und zum Auslösen von Aktionen benutzt werden, bestimmten Kriterien folgen.

URI wird oft mit URL (Uniform Resource Locater) verwechselt. URL ist eine Spezialform des URI. URLs dienen der Adressierung von Webseiten im Browser. URIs können dies und noch anderes adressieren. In URLs werden zum Anhängen von Daten Parameter benutzt, die durch ein ?-Zeichen abgetrennt sind. Diesen Teil nennt man Querystring. Folgendes sind typische Anwendungsfälle:

/admin/updatebook.aspx?book=2605

/bookview.html?book=2605

/bookreviews.py?book=2605

Der Teil book=2605 ist der Querystring. Dies ist nicht RESTful. RESTful verlangt, dass der Datenteil als Teil des URL erfasst wird. Routen – das sind Adressierungsschemata auf Basis von URIs – haben definierte Abschnitte, denen eine Bedeutung zugewiesen wird. Diese Zuweisung ist willkürlich (Sache des Entwicklers), läuft aber häufig nach einem einfachen Prinzip:

/ressource/id

Oder etwas komplexer:

/ressource/id/aktion

RESTful würden die Beispiele oben wie folgt aussehen:

/admin/book/2605

/book/2605

/book/2605/view

Freilich sind hier immer noch viele Optionen vorhanden. Deshalb ein paar Regeln:

Kurz

: Je kürzer die URI, desto besser.

Baumstruktur:

Die URI sollte die Baumstruktur des Objekt-/Datengraphen repräsentieren.

Lesbar:

Klartext hilft anderen, die Route intuitiv zu verstehen.

Voraussagbar:

Die Reaktion des Servers entspricht der Intuition beim Lesen des URI.

Substantive und Verben:

URIs adressieren

etwas

, also ist das Wort eine Sache, keine Aktion. Dazu nutzt man ein Substantiv. Wird eine Aktion gebraucht, hängt diese hinten dran, idealerweise dann als Verb.

QueryString I:

Ja, darf man benutzen, aber nur für genau dies:

query

(engl. abfragen/suchen), beispielsweise:

/books/search?filter=title&value=JADE

.

QueryString II:

Nein, nicht zu benutzten, wenn Parameter benötigt werden. Dann schreibt man beispielsweise Folgendes:

/books/select/quarter=2;year=2016

.

Deterministisch:

Die gleiche URI ergibt immer dieselbe Ressource.

Statuslos:

Kein Zustand auf dem Server hat Einfluss auf die Reaktion.

Kanonisch:

Wenn zwei URIs zur selben Ressource führen, muss die Alternative in der Antwort benannt werden.

Weniger wichtig, aber für guten Stil sinnvoll, sind folgende Regeln:

Nur Kleinschreibung benutzen:

Camel-Case und Ähnliches ist hier eher störend.

Bindestriche statt Unterstriche:

book-review

ist besser als

book_review

für Suchmaschinen.

Plural nutzen, wenn es der Kontext erwartet:

books

, wenn es sich um mehrere handelt.

Wenn Abrufe aus Kollektionen (Listen) erfolgen, sollte dies sichtbar sein:

/books/book/3

. Dann muss aber der Abruf

/books

technisch möglich sein und alle Bücher liefern. Wenn aber die Kollektion nicht geliefert werden kann, reicht

/book/3

.

Keine Leerzeichen verwenden:

%20-Fragmente machen URLs unübersichtlich.

HTTP-Methoden für REST

In REST werden spezifische HTTP-Methoden benutzt, um Aktionen auf dem Server auszulösen. Konkret eingesetzt werden:

GET:

Abrufen einer Ressource

POST:

Ändern oder Auslösen einer Aktion

PUT:

Erzeugen einer Ressource

DELETE:

Löschen einer Ressource

PATCH:

Ändern eines Teils einer Ressource

HEAD:

Metadaten anfordern

OPTIONS:

Erlaubte Aktionen auf einer Ressource

Es ist nicht zwingend notwendig, dies mit SQL zu vergleichen, ein einfaches Mapping kann REST aber durchaus darstellen:

Tabelle 1-3: Mapping von REST auf SQL

HTTP (REST)

SQL

GET

SELECT

POST

INSERT

PUT

UPDATE

DELETE

DELETE

In HTTP sieht das beispielhaft folgendermaßen aus (… steht für typische Kopffelder):

1 POST /basket/2605

2 ...

3 name=Neuer Artikelname

Hierbei ist die URI ein relativer Pfad zur Ressource. basket bezeichnet die Route zu einem Controller, der sich um den Warenkorb kümmert. Die Route erwartet eine ID, die hier 2605 enthält. Damit ist im Warenkorb ein Element mit dem Primärschlüssel 2605 gemeint. Dieses Element hat eine Eigenschaft name, der der neue Text »Neuer Artikelname» zugewiesen wird.

Mittels PUT wird eine Ressource wie folgt geändert:

1 PUT /basket

2

3 <book>

4 <title>Pug</title>

5 <desc>

6 Die Template-Engine Pug

7 </desc>

8 <price>2,99</price>

9 <type>Paperback</type>

10 </book>

Da eines der Merkmale von REST die Selbstbeschreibung ist, gibt PUT einen Link zur geänderten Ressource zurück:

1 HTTP/1.1 201 OK

2 Content-Type: text/xml;

3 Content-Length: 34

4

5 http://shop.meinefirma.de/basket/2605

Das Löschen der Ressource erfolgt ähnlich:

1 DELETE /basket/2605

Multipurpose Internet Mail Extensions (MIME)

MIME steht für Multipurpose Internet Mail Extensions und wurde ursprünglich dazu entwickelt, Dokumente in E-Mails einzubetten. Dabei wird eine beschreibende Kopfzeile (Header) benutzt, um das ursprüngliche Format anzuzeigen. Der Client kann dies dann wiederherstellen. Typisch ist die Zweiteilung des Formats und die Benutzung der Kopfzeile Content-Type:

gruppe/detail

Für ein Bild sieht das nun folgendermaßen aus:

Content-Type: image/jpeg

Eine genaue Beschreibung, die über das hier für REST benötigte hinausgeht, finden Sie unter de.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions.

Für REST wird Folgendes benutzt:

text/xml

application/json

JavaScript Object Notation (JSON)

In REST wird zur Kommunikation zwischen Client und Server meist JSON eingesetzt. JSON (JavaScript Object Notation) ist ein kompaktes Format in lesbarer Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Obwohl der Name auf eine alleinige Verwendung in JavaScript hindeutet, ist JSON ein unabhängiges Format, das theoretisch in jeder Programmierumgebung eingesetzt werden kann.

Der am meisten betonte Unterschied von JSON zu XML ist die etwas kompaktere Codierung von Datenstrukturen, wodurch im Unterschied zu XML weniger Verwaltungsdaten produziert werden. Außerdem kann JSON beispielsweise in JavaScript direkt in ein JavaScript-Objekt umgesetzt werden. XML ist hingegen vielseitiger als JSON einsetzbar, das keine Auszeichnungssprache, sondern nur ein Datenaustauschformat ist. XML genießt weiterhin eine weite Verbreitung. Beide Formate sind nicht unbedingt zum Repräsentieren von großen Binärdaten geeignet.

JSON kennt Objekte, Arrays, Zeichenketten, Zahlen, boolesche Werte und null. Daten können beliebig verschachtelt werden, beispielsweise ist ein Array von Objekten möglich. Als Zeichencodierung benutzt JSON UTF-8.

Die JSON-Formatdefinition

Ein Objekt wird mit geschweiften Klammern umschlossen { }. Es kann eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften enthalten.

JSON darf keine Kommentare enthalten, wie sie beispielsweise in JavaScript erlaubt wären.

Eine Eigenschaft besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt. Der Schlüssel ist eine Zeichenkette. Der Wert ist ein Objekt, ein Array, eine Zeichenkette, eine Zahl oder einer der Ausdrücke true, false oder null. Ein Array beginnt und endet mit eckigen Klammern [ ]. Es kann eine durch Kommata geteilte, geordnete Liste von Werten enthalten. Eine Zeichenkette beginnt und endet mit Anführungszeichen ("). Sie kann Unicode-Zeichen und Escape-Sequenzen enthalten. Ein boolescher Wert wird durch die Ausdrücke true beziehungsweise false dargestellt – ohne Anführungszeichen. Eine Zahl ist eine Folge der Ziffern 0−9. Diese Folge kann durch ein negatives Vorzeichen eingeleitet und durch einen Dezimalpunkt unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein Vorzeichen »+« oder »–« und eine Folge der Ziffern 0–9 folgt. Leerraumzeichen sind beliebig verwendbar.

Listing 1-3: Beispiel eines JSON-Blocks

1 {

2 "CreditCard" : "Visa",

3 "Number" : "1234-5678-9012-3456",

4 "Owner" :

5 {

6 "LastName" : "Krause",

7 "Firstname" : "Jörg",

8 "Gender" : "\"male\"",

9 "Preferences" : [

10 "Golf",

11 "Reading",

12 "Badminton"

13 ],

14 "Age" : null

15 },

16 "Deckung" : 10000,

17 "Währung" : "EURO"

18 }

Wenn Sie mehr über JSON lesen möchten, könnten folgende Quellen interessant sein:

json.org

bietet eine deutsche Einführung auf der offiziellen JSON-Seite.

Die RFC 4627 definiert mit

application/json

einen weiteren MIME-Typ.

Atom Syndication Format (ATOM)

ATOM steht für Atom Syndication Format, ein plattformunabhängiges Format zum Austausch von Feeds. Es hat damit denselben Zweck wie das bekanntere RSS, das in der neuesten Version 2.0 für Really Simple Syndication steht. ATOM gilt als designierter Nachfolger von RSS 2.0. ATOM selbst ist für verschiedene Zwecke definiert, wobei hier auf ASF (ATOM Syndication Format) Bezug genommen wird. Neben der reinen Feed-Verteilung kann ATOM für Newsletter und ähnliche Zwecke eingesetzt werden. ATOM wurde in der RFC 4278 veröffentlicht. Der MIME-Typ ist application/atom+xml.

Listing 1-4: Typischer ATOM-Block

1 <?xml version="1.0" encoding="utf-8"?>

2 <feed xmlns="http://www.w3.org/2005/Atom">

3 <author>

4 <name>Jörg Krause</name>

5 </author>

6 <id>urn:uuid:60a76c80-9926-9905-1964-0003939e0af6</id>

7

8 <entry>

9 <title>Neues aus der Webwelt</title>

10 <link href="http://hanser.de/2010/08/08/atom-wcf"/>

11 <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-01723243189a</id>

12 <updated>2016-12-08T12:50:07Z</updated>

13 <summary>Alles über Web</summary>

14 <content>Hier steht der gesamte Text</content>

15 </entry>

16 </feed>

In Webanwendungen wird man ATOM nur einsetzen, wenn Clients dies explizit fordern. Der Einsatz von JSON ist deutlich einfacher und schneller.

Grenzen von REST: GraphQL und OData

REST ist für kleine und mittlere Umgebungen perfekt. Es ist ausreichend, wenn die Komplexität der Abfragen überschaubar ist. Da jedoch alles eine Ressource ist, wird es mit zunehmender Anzahl dieser Ressourcen schnell unübersichtlich. An dieser Stelle sind komplexere Abfragesprachen gefragt, die Mehrfachzugriffe und Abhängigkeiten durch entsprechende Syntaxkonstrukte vereinfachen.

Etabliert haben sich hier zwei Standards:

GraphQL (siehe

graphql.org

)

Open Data Protocol (OData) (siehe

www.odata.org

)

GraphQL basiert auf JSON-Paketen, in denen eine Abfrage formuliert wird. Entsprechend muss fast immer mit POST gearbeitet werden, weil auch bei Abfragen Daten zum Server übermittelt werden. GraphQL erlaubt komplexe Konstrukte und erfordert eine explizite serverseitige Unterstützung. GraphQL ist sehr auf die Webwelt zugeschnitten und hat in reinen Webapplikationen Vorteile.

OData ist dagegen bei Abfragen URL-basiert und kann GET benutzen. Die Abfragen sind einfacher, vielfältige Filter sind aber auch hier möglich. OData ist breiter aufgestellt, wenn es um Umgebungen außerhalb der Webwelt geht.

Single Page Application (SPA)

Eine Single Page Application (SPA) (alias Single Page Web Application) ist eine Webanwendung, die keinen Seitenwechsel (Roundtrip) durchführt, sondern die Anzeige nur durch Austausch von Seitenelementen via JavaScript/DOM verändert. Es gibt dabei also keine serverseitige Seitennavigation. Die URL ändert sich nicht. Initial wird eine komplette HTML-Seite oder zumindest das Grundgerüst einer Webseite in einem HTML-Dokument von dem Server geladen. Die Seite lädt anschließend Daten über Webservices (meist REST-basierte Dienste, alias Web APIs) nach und erzeugt die Darstellung clientseitig (clientseitiges Rendern). Eine SPA wirkt damit wie eine Desktop-Anwendung.

Abbildung 1-2: Klassisches serverseitiges Rendering vs. clientseitiges Rendering moderner Webanwendungen

Asynchronous JavaScript and XML (AJAX)

Basis für Single Page Applications (SPAs) ist die Technologie Asynchronous JavaScript and XML (AJAX), die abseits der üblichen HTTP-Rundgänge (Roundtrips) Aufrufe des Webservers vom Browser ermöglicht. Der Browser löst einen AJAX-Aufruf aus gegen eine HTTP-URL. Von der URL erhält er Daten, die er zur Aktualisierung der Webseite per Document Object Model (DOM) verwendet. AJAX-Aufrufe transportieren heutzutage aber meist nicht mehr XML-Dokumente, sondern JSON-Daten.

Der Begriff AJAX wurde erstmals im Februar 2005 von Jesse James Garrett verwendet (siehe adaptivepath.org/ideas/ajax-new-approach-web-applications). Wirklich neu an AJAX war aber nur der Name; die Idee des entfernten Prozeduraufrufs aus dem Browser heraus wurde erstmals im Jahr 1998 von Microsoft im Internet Explorer 4.0 in Form des Microsoft Remote Scripting (MSRS) verwendet. MSRS basierte auf einem Java Applet. Im Internet Explorer 5.0 ist später das XmlHttpRequest-Objekt erschienen, das noch heute Basis in dieser Form im Internet Explorer und anderen Browsern existiert und jetzt den Kern von AJAX bildet. Moderne Browser verwenden aber nicht mehr das XmlHttpRequest-Objekt, sondern das Fetch API (fetch.spec.whatwg.org).

In der Regel wird weder das XmlHttpRequest-Objekt noch das Fetch API direkt verwendet, sondern Webentwickler setzen Frameworks ein, die davon abstrahieren (zum Beispiel Angular oder React).

Responsive Web Design (RWD)

Responsive Web Design (Aliase: Reactive Design, Adaptive Design, Receptive Design) bezeichnet ein Konzept im Rahmen der Gestaltung von Webseiten, das ein komfortables Lesen der Webseiten auf jeder Bildschirmgröße (auch kleinen Smartphones) ohne Scrolling erlaubt. Responsive Web Design realisiert man mit Box- beziehungsweise Flexbox-Modell in Cascading Style Sheets (CSS) direkt oder oft leichter mit darauf aufbauenden Frameworks wie Bootstrap.

Die folgenden drei Bildschirmabbildungen zeigen Responsive Web Design von drei verschiedenen Bildschirmgrößen: Bei großem Bildschirm sieht man alle drei Spalten. Bei mittlerem Bildschirm verschwindet die erste Spalte, und es erscheint ein Pfeil, um zurück zur Ansicht der Kategorien zu kommen. Bei sehr kleinem Bildschirm sieht man schließlich nur noch eine Spalte mit Pfeil.

Abbildung 1-3: Responsive Web Design bei großem Bildschirm

Abbildung 1-4: Responsive Web Design bei mittelgroßem Bildschirm

Abbildung 1-5: Responsive Web Design bei sehr kleinem Bildschirm

KAPITEL 2

Hypertext Markup Language (HTML)

Die Grundlage jeder HTML-Seite ist die Beschreibungssprache HTML – die HyperText Markup Language. Sie dient der Strukturierung der Seiten. In der aktuellen Version 5 ist außerdem der Zugriff auf das hierarchische Objektmodell der Seite geregelt, also die Zugriffe via JavaScript. CSS – Cascading Style Sheets – dienen der Gestaltung und grafischen Aufbereitung der Inhalte. CSS wird im nächsten Kapitel behandelt.

Beide Sprachen sind sehr alt und genügen heutigen Anforderungen nur unzureichend. HTML5 ist deshalb zu einem Konvolut verschiedener Standards geworden, die alle Arten von Funktionen ergänzen. Eine Übersicht wird in diesem Kapitel beschrieben. Außerdem haben sich verschiedene Template-Systeme etabliert, die die Nachteile von HTML auszugleichen versuchen. So versucht Angular nach Intention der Entwickler so etwas wie eine dynamische Erweiterung zu sein, wie sie aussehen würde, wenn sie zusammen mit HTML erfunden worden wäre.

Auch CSS ist nicht mehr sehr neu. Hier stellen komplexere Style-Systeme hohe Anforderungen. Darauf gibt es zwei Antworten. Zum einen entwickeln sich Präprozessoren wie LESS oder SASS, die dynamisches CSS definieren und dann für den Browser aufbereitet werden. Zum anderen entstehen kompexe CSS-Frameworks wie beispielsweise Bootstrap.

Grundlagen HTML

In diesem Abschnitt geht es um die Grundlagen zu HTML und einen sehr kurzen geschichtlichen Überblick.

Geschichte

Der Standard HTML ist eine Kooperation von W3C (World Wide Web Consortium) und WHATWG (Web Hypertext Application Technology Working Group). Die Prinzipien der Arbeitsgruppen sind:

Standard ist HTML + CSS + DOM + JavaScript

Keine Plug-ins (kein Java, kein Flash, kein Silverlight etc.!)

Mehr Markup; »unobtrusive«, weniger direktes Scripting

Geräteunabhängig

Eigene Implementierungen sollten diesen Prinzipien folgen!

Abbildung 2-1: Das offizielle HTML5-Logo

Tabelle 2-1: Geschichte der HTML-Versionen

Version

Jahr

HTML

1991

HTML+

1993

HTML2

1995

HTML3.2

1997

HTML4.01

1999

XHTML1.1

2001

WHATWG

2004

WHATWG und W3C Kooperation

2006

HTML5

2012

XHTML5

2013

HTML5.1

2016

HTML5.2

2017

HTML5.3

in Arbeit

XML – Grundlage für HTML

Auch wenn das Thema dieses Kapitels HTML ist, sollten Sie sich über den grundsätzlichen Aufbau eines XML-Dokuments (Extensible Markup Language) im Klaren sein. Beide Standards gehen auf denselben Stamm zurück und sind sogenannte Markup-Sprachen – Markup Languages. Dieser Begriff ist für das »ML« in den Namen verantwortlich. Im Gegensatz zu Programmiersprachen dienen Markup-Sprachen dazu, Inhalte zu beschreiben. An dieser Stelle werden nur die notwendigsten Eigenschaften vermittelt.

Markup

Als Markup bezeichnet man alle Zeichengruppen, die eine Struktur in XML definieren:

Start-Tags:

<startTag>

End-Tags:

</endTag>

Leerelemente:

<Leerelement />

Entitätsreferenzen:

&amp;

Zeichenreferenzen:

&x0f;

Kommentare:

<!-- Kommentar -->

CDATA-Bereichsbegrenzer:

<![CDATA[ kein XML ]]>

Dokumententypdeklarationen:

<!DOCTYPE HTML>

Verarbeitungsanweisungen:

<? include ("datei.php") ?>

Die XML-Deklaration:

<?xml version="1.0"?>

Textdeklarationen:

<?xml encoding="utf-8" ?>

Alles andere ist Text. Dabei sind drei Sonderzeichen zu beachten, die das oben genannten Markup steuern:

&gt; steht für

<

&lt; steht für

>

&amp; steht für

&

Für Attributwerte, die Anführungszeichen enthalten, kommen noch zwei Entitäten hinzu:

&quot; steht für

"

&apos; steht für

'

Eine Besonderheit stellen CDATA-Bereiche dar. In diesen sind die üblichen Regeln außer Kraft gesetzt, und eine Codierung der speziellen Zeichen muss nicht stattfinden:

<![CDATA[ hier & hier ist "kein" <XML> ]]>

XML-Dokumente

XML-Dokumente gehorchen in ihrem Aufbau festen Regeln. Erst durch diese Regeln kann eine automatisierte Verarbeitung in derart umfassender Form stattfinden, wie sie erforderlich ist. Auf der anderen Seite sollte der Einsatz so universell wie möglich sein, wie der Name »eXtensible Markup Language« suggeriert.

Wohlgeformtheit

Die Regeln erlauben die Prüfung der Wohlgeformtheit von Dokumenten durch das verarbeitende Programm ohne Kenntnis der Grammatik der von Ihnen konkret eingesetzten Sprache. Der Begriff Wohlgeformtheit, im englischen »well formed« genannt, ist ein Basismerkmal von Markup-Sprachen. Als wohlgeformt gilt ein Dokument, wenn folgende Merkmale zutreffen:

1. Alle Tags sind syntaktisch korrekt. Dazu gehört, dass Anfangs- und Endtag übereinstimmen, wobei Groß- und Kleinschreibung zu beachten ist (

<tag></Tag>

wäre unzulässig). Zu jedem öffnenden Tag muss ein schließendes existieren (

<tag></tag>

). Alternativ kann ein Tag direkt geschlossen werden (

<tag/>

).

2. Alle Attribute sind syntaktisch korrekt. Parameter der Attribute müssen immer in Anführungszeichen stehen (

<tag attr="param">