APPE

Transaktionen verursachen eine enge semantische Kopplung → Mit SAGA Pattern arbeiten.

• Logging findet auf verschiedenen Systemen, ggf. mit verschiedenen Sprachen und Frameworks statt.
• Stark verteilte Datenhaltung, Netzwerkinfrastruktur, unter Umständen auch in der Cloud und Serverless!
• Durch (gewollte) möglichst lose Kopplung verliert man ggf. die Nachverfolgbarkeit (Traceability) von Businessprozessen.

Wenn ein Service eine Anzahl von Folgeaktivitäten (weitere Services) aufruft und diese asynchron durch Queues verzögert ausgeführt werden.

Lösung:
Man verpasst jedem Client-Request einen Fingerabdruck (Correlation-ID) und reicht diesen konsequent an alle Unter- bzw. Folgeaufrufe weiter. Somit wird unabhängig vom zeitlichen und örtlichen Kontext ein kompletter Request relativ einfach nachvollziehbar.

Universally Unique Identifier

Ein UUID besteht aus einer 16-Byte-Zahl, die hexadezimal notiert und in fünf Gruppen unterteilt wird.

• Historisch existieren fünf verschiedenen Varianten (Type 1 - 5).
• Konkretes Beispiel für Java: Klasse java.util.UUID produziert mit randomUUID() pseudozufällige Type 4 UUIDs.
• Beispiel: 4e6abea6-d18a-49c1-a7b0-4f57702e6602
• Schnelle Generierung möglich, typisch kein Problem.

Sind explizit in die Software eingebaute Messpunkte, welche einen Rückschluss auf die Leistung eine (Teil-)Systems erlauben.

• Zähler (counter) der die Anzahl Ereignisse kumuliert
• Messwert (gauge): Absoluter Wert (Anzahl Elemente in Queue)
• Meter (meter): Messwert/Zeiteinheit (Ereignisse pro Min.)
• Histogramme: Statische Verteilungen von Messwerten (z.B: Min, Max, Mittelwert etc.)

Schnittstelle die explizit darauf ausgelegt ist, eine Softwareeinheit nutzbar zu machen.

• Möglichst einfache Nutzung
• Soll Aufwand für Nutzer minimieren
• Soll Unabhängigkeit von einer konkreten Implementation bieten

Wird typisch vom Nutzer verwendet und vom Anbieter implementiert.

Besteht typischerweise aus mehreren Klassen/Interfaces.

Definiert gemeinsame Funktionen (Interfaces) und Datentypen

Ist eine Frage des Scopes.

Die Definition, welchen Scope und somit welche «Wichtigkeit» eine Schnittstelle hat, erfolgt auf Architektur-Ebene.

• Somit nicht primär technisch getrieben!

Info:

Eine rein technisch betrachtet identische Schnittstelle kann:

• Im (Detail-)OO-Design in einer Implementation existieren.
• Die Schnittstelle zu einer Komponenten darstellen.
• Die Schnittstelle zu einem Framework darstellen.
• Die Schnittstelle zu einem Teilsystem darstellen.
• Die Schnittstelle zu einem vollständigen System darstellen.

Der Scope und die Wichtigkeit wird auf Architekturebene festgelegt.

• Fördern die Modularität und Entkopplung
• Machen komplizierte Dinge möglichst einfach nutzbar
• Machen die Implementation austauschbar
• Machen das Produkt attraktiv
• Binden die Nutzer
• Nutzer investieren in API Schulung

• Verursachen Ärger und Kosten
• Fehlerhafte Nutzung und aufwendige Fehlersuche
• Verführen dazu eine vorhandene Lösung nicht zu nutzen und etwas selber zu machen
• Verführen zu unsauberen Arbeiten

• APIs leben fast ewig → auch derer Fehler
• Nur mit grossem Aufwand und Konsequenzen änderbar
• Grosse Kunst: API so zu entwerfen, dass sie entwicklungsfähig ist.

• Maximale Entkopplung
• Maximales Information Hidding
• Maximale Kohäsion

• Konsistent → Namensgebung und Regeln konsequent einhalten
• Namensgebung → Einfache, eingängige treffende Namen wählen
• Verhalten → Klare Erwartungen erfüllen, ohne Nebeneffekte
• Erweiterbarkeit → Offen für Weiterentwicklung
• Dokumentation → Einfache und hilfreiche Doku
• Perspektive → Es soll für den Nutzer einfach sein
• Sicherheit → Die Nutzung soll sicher sein

Werden verwendet, um in APIs die Namensgebung und das Verhalten möglichst vorhersehbar und durchgängig zu gestalten.

Bsp:
Repetition
Verwende immer den gleichen Namen für die gleichen Dinge.

Periodisch
Verwende immer die gleiche Bezeichnung für gleiches Verhalten.

Symmetrie
Biete wenn möglich symmetrische Methode an, z.B. für das Öffnen und Schliessen, oder das Belegen und Freigeben.

Der Nutzer selber sowie auch der Anbieter.

JDBC als API zu Datenbanken. REST

• Eine spezielle Teilmenge oder Ergänzung zu einer API
• Ist für Anbieter gedacht
• Kann verschiedene Konfigurationen anbieten
• Kann eine Konfig-Datei sein (Properties)
• Die bewusste Abgrenzung durch ein explizites SPI verbessert die Gesamt-API und schützt sie massgeblich vor falscher Nutzung.

• Werden über ein oder mehrere Klassen realisiert
• Typisch in einem Package oder Modul abgeschlossen
• Geschichtete Architekturen → Datentypen zwischen Schichten brechen!

Fliessend lesbarer Code für die API:

CRUD = Creat / Read / Update / Delete.CRUD ist ein Akronym für die vier fundamentalen Operationen des Datenmanagement

Bild

REpresentational State Transfer

REST ist ein Architekturstil und definiert einen Satz von Prinzipien, welche eine konkrete, REST-konforme Architektur einhalten soll.

Die wesentlichen REST-Prinzipien sind:

• Statuslose Kommunikation (Zustandslosigkeit)
• Ressourcen mit eindeutiger Identifikation (URI)
• Verwendung von (http-)Standardmethoden
• Hypermedia-Prinzip (Hinter diesem Prinzip steht das Konzept von Verknüpfungen von unterschiedlichen Ressourcen über Links.)
• Unterschiedliche Repräsentation von Ressourcen (Darstellung der Informationen)

• Auf einer verteilten Client-Server Architektur, meist http-Protokollen
• RESTfull verlangt, dass jedoch unterschiedliche Protokolle genutzt werden können

• Zustandslos
• Zustand wird von Client gehalten, oder vom Server in einem veränderten Ressourcenstatus abgebildet

• Der Status der Applikation ergibt sich ausschliesslich aus der Ressourcenrepräsentation (URI) und dem Ressourcenstatus.

  - Es dürfen keine Sitzungsinformationen existieren. Keine serverseitige «Session»!

Eine Ressource ist einen Informationseinheit, welche über eine URI eindeutig identifiziert bzw. angesprochen werden kann. Sie kann verschieden Datenformate nutzen.

Enthalten keine Namen von Operationen. Bsp:

Ist das Prinzip von Verknüpfungen von unterschiedlichen Ressourcen über Links.

Wenn der Client eine Antwort bekommt, kann er die enthaltenen Verknüpfungen verwenden bzw. ihnen "folgen".

(Siehe Bsp.)

Hypermedia As The Engine Of Application State

Zur Beurteilung ob einer Applikation die wesentliche REST-Prinzipien einhaltet:

Level 0: Swamp of the POX (Plain old XML) --> Verwenden von HTTP und XML
Level 1: Verwenden von eindeutigen URIs
Level 2: Verwenden von de Htttp-Standart-MethodenLevel
3: Verwenden von Links zur Navigation (Resource wird angefragt und bekommt weiter links zurück zu weitern Resourcen)
Content-negotiation: Es wird ausgehandelt (definiert) in welcher Repräsentation die Recource übermittelt wird. (Wird in Header festgelegt)