Teil2

Spezielle Klassen

• implementieren servlet interface

• von web-container verwaltet

• HTTP-Anfragen verarbeiten und beantworten

Lebenszyklus:

• Initialisierungsphase

  • beim Entreffen einer Anfrage oder hochfahren des Containers

  • erzeugt servlet-objekt

  • init methode erhält Servletconfig-objekt als Parameter, gibt Zugriff auf Konfiguration des Servlets

• Servicephase

  • jede Anfrage an Servlet erzeugt thread

  • innerhalb thread request und response objekt erzeugt

    • objekte rufen service methoden auf

• Beendigungsphase

  • entfernen Servlet mit destroy methode

  • überschreibbar

nutzt Front controller Muster

• alle eintreffenden Anfragen über zentrales controller-servlet (DispatcherServlet)

  
  

Aktionsbasiert

• arbeiten direkt mit ankommenden HTTP Request

• In HTTP Request erhalten informationen werden vom Front-Controller ausgewertet und an spezialisierte Controler weitergleitet

  • Spez. Controller führt entsprechende Aktionen aus

• Views greifen zum Rendern auf zugehörigen Models zu

• View-Technologien meist nicht festgelegt

• validierung und datenkonventierungen müssen entwicklet werden

Komponentenbasiert

• konkrete Verarbeitung von HTTP-Requests wird vor entwickler versteckt und durch framework übernommen

• Logik in Komponenten gekapselt, erhöht Wiederverwendbarkeit

• Seite aus hierarchie von Komponenten

  • framework verwaltet serverseitig Repräsentation dieser Hierarchi

  • Komponenten durch Framework gerendert

  • dev kombiniert vorgefertige Komponenten und schreibt glue-code

  • Validierung und Konvertierung durch Framework übernommen

muss beim Container registriert werden

über Konfigurationsdatei oder Servlet-API

in Spring Boot keine weiteren Schritte notwendig

• wDispatcher Servlet automatisch konfiguriert wenn spring-webmv im Klassenpfad gefunden

Behandeln/Auswerten von Anfragen

• mit handler-methoden

• mittels requestmapping handler zuweisen

• beschränkung auf bestimmte HTTP-Methoden möglich

  • mit method attribut der annotation

  • mit spezieller annotation zB GetMapping

• Parameter entweder Explizit mit RestParam oder ohne Angabe dann wird Name der annotierten Methode verwendet

Aufrufen von Fachlogik (unterschied zu reinen mvc)

• controller keine fachlogik, seperation of concern

• fachlogik in service

• service aufruf per autowiring

Erzeugen der Antwort

• zwei Arten

  • Befüllen/Manipulieren des Models sowie bestimmung der anzuzeigend View (Model-view-rendering)

    • model gibt daten an view

  • direktes schreiben in den Response-Body

uri dynamischen anteil

bei bedarf über regex einschränken

pathvariable annotation nötig für zugriff auf url

explizit oder weglasen der Pfadvariable namen möglich

kopf von handler-methoden in einem controller ist flexibel

• gilt für Methodenparameter sowie Rückgabewert

Framework injiziert Werte der deklarierten Methodenparameter bzw. interpretiert den Rückgabewert

bsp. @RequestParam, @PathVariable

java-template-engine

unterstützt html, css, js, xml, plain-text

anpassbar und erweitbar über dialekte

dynamishen Anteil des Tempaltes in Ausdrücken angaben

einbindung einer View-Technologie über View-Resolver

muss konfiguriert werden

bildet vom Controller gelieferten logischen View-Namen auf konkrete View ab

mit spring boot keine weiteren schritte nötig

liefert logische Sicht auf Software-Komponente

Dient der Modulariserung und Integration von Systemen

spezifiziert

• unterstützte Funktionen und Datentypen

• Verfügbare Varianten (Versionierung)

• Technische und organisatorische Rahmenbedingungen für die Nutzen zB rate limit, gebühren

Public, private APIs

Apis der web.Plattform

• definiert Programmierschnittstellen zur Nutzung in Web-Browsern und Servern

• zb DOM, fetch

Web APIs für Services

• Integration von verteilten Komponenten einer Web-Anwendung sowie von ganzen systemen

• beschreibt Serices, die für Clients zur Verfügung gestellt werden

• z.B. über ajax Daten von backend

• web-app lagert bestimmte funktionalitäten auf cloud-basierte Dienste aus zB Kreditkartenzahlugn

• technologien für realisierung

  • rest

  • graphql

  • gRPC

  • SOAP

Representational State Transfer

Architekturstil für Entwcklung von services

• Sammlung von Konzepten und Prinzipien

aus WWW prinzipien abgeleitet

• services wie normale Ressourcen angesprochen werden

  
  

Sicher (safe)

• Operation führt zu keine Zustandsänderung auf dem Server

• seiteneffekte wie Logging erlaubt

Idempotent

• Operation garantiert, das mehrmaliges Senden der identischen Abfrage die gleichen Seiteneffekte wie ein einmaliges Senden bewirkt

View und Model entfallen

• kein Model-View-Rendering

@RestController Annotation verwenden

• Kombiniert Controller und ResponseBody

gleiche API wie für Model-And-View-Rendering

• Get, Post Mapping ..

• Media-Types mit produces und consumes einschränken

• ResponseStatus für HTTP-Statuscodes

Aufbau rest-api enthält oft implizite Annahmen über Anforderung aufrufender Clients

Bei variationen von unterschiedlichen Anforderungen des Clients muss API flexibilität gewährleisten

Rest-api liefert aggregierte Daten

• passend für client welche die aggregierten Daten benötigten, zB todos und comment gemeinsam anzeigen/verarbeiten

• falls nicht benötigt zuviel daten -> overfetching

Rest-API aggregiert nicht, gibt seprate Endpunkte für Objektbeziehungen

• zb comment für todo über separaten Endpunkt ziehen

• passend für client, welche die aggregierten daten nicht benötigten

• falls doch nötig, mehrere Anfragen da einzelne Anfrage zu wenig Daten -> underfetching

Client können gezielte Anfragen an die API stellen, die exakt spezifizieren, welche Daten geliefert werden sollen

unterstützung zwei Komponenten

• Sprache zur Abfrage und Maniplation von Daten durch Clients sowie zur Definition eines Schemas

• Laufzeitumgebung zur serverseitigen Ausführen von Anfragen

Daten als Graphstuktur begriffen, aus welcher Subgraphen selektiert werden können

gesamte API über ein Endpunkt verfügbar

struktur der Daten muss bekannt sein damit serverseite laufzeitumgebung Anfrage verstehen und auswerten kann

Sturktur in schema spezifiziert

syntaktisch an JSON angelehnt

definiert

• untersützte Datentypen

• mögliche operationen

  • queries (lesend)

  • Mutations (schreibend)

  • Subscriptions (ereignisbasiertes Abonnieren von Änderungen)

Typen

• Skalare Typen (int float, string ,boolean, id)

• Objekttypen (type Todo)

  • kann 0 oder mehr Argumente besitzen

  • wichtig für spezifikation von Operationen

• Enumeration

  • aufzählungstypen mit festem Wertebereich

• Query, Mutation, Subscription Typen

  • Einsteigspunkte für das Schema, jede Anfrage beginnt bei Einstiegspunkt

• Interfaces

• Vereiniungstypen

• Direktiven

Laufzeitumgebung

verschiedene Programmiersprachen unterstützt

client kann Struktur es Schemas selbst inspizieren (Introspektion, wie Reflection in Java)

ermöglicht dynmaische Clients

in Anfrage über Meta-Felder möglich

• zugriff auf schema

• zugriff auf typen

Schema First

• schema manuell spezifiziert

• implementiert auf basis entsprechenden laufzeitumgebungen

Code-first

• Implementierung mit Hilfe von dediziertem (zb Glue-Code) oder angereichertem Code (zb Annotation)

root-types des Schemas müssen in Form von entsprechenden Root Resolvern implementiert werden

Resolver in Sprint Boot als Controller realisiert

für jede Feld (dh jede Operation) des Root-Typen müssen Resolver passende Methoden enthalten

verbindung methode und feld über Annotation

• @QueryMapping

• @MutationMapping

• @SubscriptionMapping