Webservices und APIs

In dieser Lerneinheit tauchst du in die Welt der Webservices und APIs ein und lernst die Grundlagen serviceorientierter Architekturen (SOA) sowie moderner Microservices kennen. Du verstehst die verschiedenen Architekturmuster und deren praktische Anwendung in verteilten Systemen, was dir bei der Entwicklung skalierbarer Webanwendungen hilft. Durch das Verständnis dieser Konzepte kannst du eigenständig Services entwickeln und in bestehende Systemlandschaften integrieren.

Einführung

Stell dir vor, du arbeitest an einem Projekt mit mehreren Teams. Das Frontend-Team baut eine Web-App, das Mobile-Team eine Smartphone-Anwendung und das Backend-Team stellt Daten bereit.

Wie kommunizieren all diese Systeme miteinander? Wie stellst du sicher, dass die Schnittstellen sauber definiert sind und verschiedene Technologien zusammenarbeiten können?

Webservices und APIs sind die Antwort. Sie ermöglichen die Kommunikation zwischen verteilten Systemen und bilden das Rückgrat moderner Webanwendungen.

In dieser Lerneinheit lernst du die wichtigsten API-Architekturen kennen: von serviceorientierten Architekturen (SOA) über REST und SOAP bis hin zu modernen Ansätzen wie gRPC und GraphQL.

Lernziele

Nach dieser Lerneinheit kannst du:

Serviceorientierte Architekturen (SOA) und Microservices erklären und voneinander abgrenzen
Die 6 REST-Prinzipien verstehen und anwenden
SOAP, gRPC und GraphQL als alternative API-Protokolle kennen
Entscheiden, welche API-Technologie für welchen Anwendungsfall geeignet ist
Die Vor- und Nachteile verschiedener API-Architekturen beurteilen

Überleitung

APIs und Webservices bilden die Grundlage für die Kommunikation zwischen verteilten Systemen. Sie ermöglichen es verschiedenen Anwendungen, Daten auszutauschen und Funktionen bereitzustellen.

Wir beginnen mit Architekturmustern: Zuerst schauen wir uns serviceorientierte Architekturen (SOA) und Microservices an. Danach lernst du die wichtigsten API-Protokolle kennen.

Serviceorientierte Architekturen (SOA)

SOA ist ein Architekturmuster, das Dienste innerhalb verschiedener Systeme eines Unternehmens miteinander verbindet. Es ermöglicht die Wiederverwendung von bestehenden Komponenten.

Die vier Schlüsselmerkmale von SOA:

Lose Kopplung: Dienste sind unabhängig voneinander. Änderungen an einem Dienst beeinflussen andere nicht.
Abstraktion: Die inneren Funktionsweisen sind verborgen. Nur die Schnittstelle wird veröffentlicht.
Wiederverwendbarkeit: Dienste können in verschiedenen Kontexten genutzt werden.
Autonomie: Jeder Dienst ist für seine eigene Funktionalität verantwortlich.

Beispiel: In einer Banking-App verbindet SOA verschiedene Dienste wie Kontostandsabfragen, Überweisungen und Kreditanträge. Diese Dienste werden sowohl für die Web-App als auch für die Mobile-App wiederverwendet.

Microservices-Architektur

Microservices sind eine Weiterentwicklung von SOA. Die Anwendung wird als Sammlung kleiner, unabhängiger Dienste gestaltet, die spezifische Geschäftsziele erfüllen.

Die vier wichtigsten Merkmale:

Fein granuliert: Jeder Microservice ist um eine spezifische Geschäftsfähigkeit herum gebaut (z.B. “Produktsuche”).
Unabhängigkeit: Services können unabhängig entwickelt, bereitgestellt und skaliert werden.
Technologieheterogenität: Teams wählen ihre Technologien frei (Java, Python, Node.js).
Dezentralisierte Datenverwaltung: Jeder Service hat seine eigene Datenbank.

Beispiel: Eine E-Commerce-Plattform wird in Mikroservices unterteilt: Produktsuche, Bestellungen, Kundenbewertungen, Zahlungsabwicklung. Jeder Service kann unabhängig skaliert und weiterentwickelt werden.

SOA vs Microservices im Vergleich

Obwohl Microservices auf den Prinzipien von SOA aufbauen, gibt es wichtige Unterschiede:

Kriterium	SOA	Microservices
Granularität	Gröber (größere Services)	Feiner (kleinere Services)
Kommunikation	Enterprise Service Bus (ESB)	Leichtgewichtige Protokolle (HTTP/REST)
Datenmanagement	Zentralisierte Datenbank	Dezentral (jeder Service hat eigene DB)
Technologiestack	Meist einheitlich	Heterogen (jeder Service wählt selbst)
Deployment	Monolithisch oder größere Einheiten	Unabhängig pro Service

Was ist ein Enterprise Service Bus (ESB)? Ein ESB ist eine zentrale Middleware-Komponente in SOA-Architekturen. Er koordiniert die Kommunikation zwischen Services, transformiert Datenformate und routet Nachrichten. Bei Microservices wird stattdessen auf direkte, leichtgewichtige Kommunikation gesetzt.

Wann welches Muster?

SOA: Große, komplexe Unternehmenssysteme mit Bedarf an zentralisiertem Datenmanagement
Microservices: Projekte mit Fokus auf Agilität, Unabhängigkeit und schnellen Deployment-Zyklen

REST und die 6 Grundprinzipien

REST (Representational State Transfer) ist ein Architekturstil für Web Services. RESTful APIs basieren auf folgenden sechs Prinzipien:

1. Client-Server-Architektur: Klare Trennung zwischen Client (stellt Anfragen) und Server (verwaltet Ressourcen). Beide können unabhängig weiterentwickelt werden.

2. Stateless (Zustandslos): Jede Anfrage enthält alle nötigen Informationen. Der Server speichert keinen Sitzungszustand.

Beispiel für Stateless: Authentifizierung mit JWT-Token
GET /api/users/123
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Der JWT-Token enthält alle Authentifizierungsdaten. Der Server muss keine Session speichern.

3. Cacheable: Antworten müssen als cacheable oder non-cacheable markiert sein. Dies verbessert Performance und Skalierbarkeit.

4. Einheitliche Schnittstelle: Standardisierte HTTP-Methoden (GET, POST, PUT, DELETE) und URI-Strukturen vereinfachen die Architektur.

5. Layered System: Zwischenserver (z.B. Load Balancer, Caches) können transparent eingefügt werden, ohne dass der Client dies bemerkt.

6. Code on Demand (optional): Server können ausführbaren Code an Clients senden (z.B. JavaScript).

HTTP-Methoden in RESTful APIs

RESTful APIs verwenden standardmäßige HTTP-Methoden, um Operationen auf Ressourcen auszuführen:

HTTP-Methode	Zweck	Beispiel
GET	Daten abrufen (lesend)	`GET /api/users/123`
POST	Neue Ressource erstellen	`POST /api/users`
PUT	Ressource vollständig ersetzen	`PUT /api/users/123`
PATCH	Ressource teilweise aktualisieren	`PATCH /api/users/123`
DELETE	Ressource löschen	`DELETE /api/users/123`

Ressourcen und URIs:

Eine Ressource ist ein Objekt oder eine Sammlung von Objekten. Jede Ressource wird durch eine URI (Uniform Resource Identifier) identifiziert.

GET /api/users/123

Diese Anfrage ruft Daten des Benutzers mit der ID 123 ab. Der Server antwortet mit den Benutzerdaten im JSON-Format:

{
  "id": 123,
  "name": "Max Mustermann",
  "email": "max@example.com"
}

Best Practice: URI-Struktur sollte die Hierarchie und Beziehungen zwischen Ressourcen widerspiegeln: /api/users/123/orders für die Bestellungen von User 123.

⏳ Lädt Dataview-Inhalt...

SOAP - Simple Object Access Protocol

SOAP ist ein Protokoll für den Austausch strukturierter Informationen in verteilten Systemen. Es basiert auf XML für das Nachrichtenformat.

Wichtige Merkmale von SOAP:

Protokoll-unabhängig: SOAP funktioniert über verschiedene Protokolle wie HTTP, SMTP, TCP oder UDP
Erweiterbar: Eigene Protokolle und Verarbeitungslogik können implementiert werden
Neutral: Unterstützt alle Programmiersprachen, da es auf XML basiert

SOAP Nachrichtenstruktur:

Eine SOAP-Nachricht besteht aus einem Envelope (Umschlag), der einen Header und einen Body enthält:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header>
        <!-- Header-Informationen (optional) -->
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <!-- Die eigentliche Nachricht -->
        <GetUserRequest>
            <UserId>123</UserId>
        </GetUserRequest>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Envelope: Der äußere Container, der die gesamte Nachricht umschließt

Header: Enthält Meta-Informationen wie Authentifizierung oder Routing (optional)

Body: Enthält die eigentliche Anfrage oder Antwort

gRPC - High Performance RPC Framework

gRPC ist ein modernes High Performance Remote Procedure Call (RPC) Framework von Google. Es nutzt HTTP/2 für Transport und Protocol Buffers (Protobuf) als Datenformat.

Wichtige Merkmale:

Schnelligkeit: Durch HTTP/2 und Protobuf deutlich schneller als REST/JSON
Plattformübergreifend: Unterstützt viele Programmiersprachen
Streaming: Server- und client-seitiges Streaming möglich

Protobuf Service Definition:

Services werden in .proto Dateien definiert. Die Field Numbers (= 1, = 2) sind dabei wichtig für die Serialisierung:

syntax = "proto3";
 
package example;
 
// Service mit einer Methode
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}
 
// Request-Nachricht
message HelloRequest {
  string name = 1;  // Field Number 1
}
 
// Response-Nachricht
message HelloReply {
  string message = 1;  // Field Number 1
}

Was bedeuten die Field Numbers (= 1)? Diese Nummern identifizieren Felder eindeutig. Sie werden für die Serialisierung verwendet und sollten nie geändert werden, da sonst die Kompatibilität verloren geht.

proto3: Die neueste Version der Protobuf-Syntax

Code-Generierung: Aus der .proto Datei wird automatisch Code für Client und Server in deiner gewünschten Sprache generiert.

SOAP vs gRPC im Vergleich

Beide Protokolle haben unterschiedliche Stärken für verschiedene Anwendungsfälle:

Kriterium	SOAP	gRPC
Datenformat	XML (text-basiert)	Protocol Buffers (binär)
Transport	HTTP, SMTP, TCP, UDP	HTTP/2
Performance	Langsamer (XML Overhead)	Sehr schnell (binär, HTTP/2)
Lesbarkeit	Gut lesbar (XML)	Nicht human-readable (binär)
Streaming	Nicht unterstützt	Bidirektionales Streaming
Browser-Support	Ja	Begrenzt (benötigt Proxy)
Tooling	Sehr ausgereift (WSDL)	Modern, wachsendes Ökosystem

Wann SOAP verwenden?

Unternehmenskritische Anwendungen mit komplexen Sicherheitsanforderungen (WS-Security)
Transaktionsmanagement erforderlich (ACID-Garantien)
Legacy-Systeme, die bereits SOAP einsetzen
Formale Verträge via WSDL erwünscht

Wann gRPC verwenden?

Microservices mit hohem Durchsatz
Echtzeit-Kommunikation mit Streaming
Interne APIs zwischen Services (nicht öffentlich)
Performance-kritische Anwendungen

GraphQL - Flexible Query Language

GraphQL ist eine Abfragesprache für APIs, die von Facebook entwickelt wurde. Im Gegensatz zu REST mit vielen Endpunkten nutzt GraphQL einen einzigen Endpunkt.

Schlüsseleigenschaften:

Einziger Endpunkt: Alle Anfragen gehen an /graphql
Präzise Datenabfrage: Client fragt nur die benötigten Felder ab
Starke Typisierung: Schema definiert alle verfügbaren Typen und Operationen
Introspektiv: Schema kann zur Laufzeit abgefragt werden

Vollständiges Beispiel:

1. Schema definieren:

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}
 
type Post {
  id: ID!
  title: String!
  content: String!
}
 
type Query {
  user(id: ID!): User
}

2. Query ausführen:

query {
  user(id: "1") {
    name
    email
    posts {
      title
    }
  }
}

3. Response erhalten:

{
  "data": {
    "user": {
      "name": "Max Mustermann",
      "email": "max@example.com",
      "posts": [
        {"title": "Mein erster Post"},
        {"title": "GraphQL lernen"}
      ]
    }
  }
}

Der Client erhält exakt die angefragten Felder - nicht mehr, nicht weniger.

GraphQL Mutationen und Subscriptions

Neben Abfragen unterstützt GraphQL auch Mutationen (Datenänderungen) und Subscriptions (Echtzeit-Updates).

Mutationen - Daten ändern:

mutation {
  createPost(title: "Neuer Post", content: "Inhalt") {
    id
    title
  }
}

Response:

{
  "data": {
    "createPost": {
      "id": "42",
      "title": "Neuer Post"
    }
  }
}

Subscriptions - Echtzeit-Updates:

Subscriptions ermöglichen es, Clients über Änderungen zu informieren:

subscription {
  postCreated {
    id
    title
    author {
      name
    }
  }
}

Der Client erhält automatisch eine Nachricht, sobald ein neuer Post erstellt wird.

Anwendungsfall: Chat-Anwendungen, Live-Dashboards, Benachrichtigungssysteme

REST vs GraphQL im Vergleich

REST und GraphQL verfolgen unterschiedliche Ansätze für API-Design. Während REST auf vielen Endpunkten und standardisierten HTTP-Methoden basiert, nutzt GraphQL einen einzigen Endpunkt mit flexibler Query-Sprache.

Kriterium	REST	GraphQL
Endpunkte	Viele (z.B. `/users`, `/posts`)	Einer (`/graphql`)
Datenabfrage	Server bestimmt Felder	Client wählt Felder
Overfetching	Häufig (zu viele Daten)	Vermieden (nur gewünschte Felder)
Underfetching	Mehrere Requests nötig	Eine Query für komplexe Daten
Caching	HTTP-Caching einfach	Komplexer (alle POST zu `/graphql`)
Lernkurve	Flach (HTTP-Kenntnisse)	Steiler (Schema, Queries lernen)
Tooling	Weit verbreitet	Sehr gut (GraphiQL, Apollo)

Vorteile

REST	GraphQL
Einfaches HTTP-Caching	Effizienter Datenabruf (eine Query statt mehrere Calls)
Flache Lernkurve	Keine API-Versionierung nötig (Schema erweitern)
Weit verbreitetes Tooling	Starke Typisierung (Fehler zur Entwicklungszeit)
Gut für öffentliche APIs	Flexible Client-Anforderungen

Herausforderungen

REST	GraphQL
Overfetching/Underfetching	Komplexes Setup und Schema-Design
Mehrere Requests für komplexe Daten	HTTP-Caching nicht direkt nutzbar
Versionierung bei Breaking Changes	Schlecht strukturierte Queries ineffizient

⏳ Lädt Dataview-Inhalt...

Zusammenfassung

Du hast einen umfassenden Überblick über die wichtigsten API-Architekturen und Webservice-Protokolle erhalten:

Architekturmuster

SOA (Service-Oriented Architecture): Große, unternehmensweite Systeme mit zentralisiertem Datenmanagement und Enterprise Service Bus (ESB)
Microservices: Fein granulierte, unabhängige Services mit dezentraler Datenhaltung und heterogenen Technologie-Stacks

API-Protokolle

REST: Zustandslose, HTTP-basierte APIs mit 6 Grundprinzipien - ideal für einfache CRUD-Operationen
SOAP: Protokoll-unabhängiges, XML-basiertes Protokoll für unternehmenskritische Anwendungen mit komplexen Sicherheitsanforderungen
gRPC: High-Performance RPC-Framework mit HTTP/2 und Protocol Buffers - perfekt für Microservices mit hohem Durchsatz
GraphQL: Flexible Query-Language mit einem Endpunkt - effizient für komplexe Datenbeziehungen und mobile Apps

Du kannst jetzt entscheiden, welche Technologie für welchen Anwendungsfall geeignet ist, und die Vor- und Nachteile verschiedener Ansätze bewerten.

Ausblick

In der nächsten Lerneinheit beschäftigst du dich mit Sicherheit von Webanwendungen.

SkillForge | ATLAS

Explorer

Webservices und APIs

Webservices und APIs

Einführung

Lernziele

Nach dieser Lerneinheit kannst du:

Überleitung

Serviceorientierte Architekturen (SOA)

Microservices-Architektur

SOA vs Microservices im Vergleich

REST und die 6 Grundprinzipien

HTTP-Methoden in RESTful APIs

SOAP - Simple Object Access Protocol

gRPC - High Performance RPC Framework

SOAP vs gRPC im Vergleich

GraphQL - Flexible Query Language

GraphQL Mutationen und Subscriptions

REST vs GraphQL im Vergleich

Vorteile

Herausforderungen

Zusammenfassung

Zusammenfassung

Architekturmuster

API-Protokolle

Ausblick

Graphansicht

Inhaltsverzeichnis

Backlinks