Übung: Funktionen für einen Uber-Konkurrenten planen

Stellen Sie sich vor, Sie gründen heute einen Uber-Konkurrenten. Überlegen Sie:

Schritt 1: Funktionale Anforderungen

• Welche Hauptfunktionen braucht Ihre Plattform, um erfolgreich zu sein? Beispiele:
  • Routenplanung
  • Zahlungssysteme
  • Kommunikation

Schritt 2: Entscheidung: Selber bauen oder zukaufen?

• Für jede Funktion müssen Sie entscheiden, ob Sie diese selbst entwickeln oder zukaufen.
• Auf welcher Basis treffen Sie diese Entscheidung?

Von Datenbanken zu APIs

Wie können Daten oder Funktionen als APIs bereitgestellt werden?
Welche Komponenten werden benötigt?

1. Datenquelle
   • Typischerweise eine (relationale) Datenbank.
   • Beispiel: Kundeninformationen, Produktkataloge oder Transaktionsdaten.
2. Applikation
   • Stellt auf der Basis der Daten Funktionen zur Verfügung.
   • Beispiel: Bestellung anlegen, Kunden über Status des Auftrags informieren.
3. Datenformat
   • Daten müssen in ein plattformunabhängiges Format serialisiert werden.
   • Beispiel: EDIFACT, XML, JSON
4. Protokoll
   • Kommunikation erfolgt über standardisierte (Netzwerk)Protokolle.
   • Beispiel: SOAP, HTTP

JSON-Syntax

Datentypen

1. Strings: Zeichenketten in doppelten Anführungszeichen (" ").

   "name": "Mountain Bike"
   

2. Numbers: Ganzzahlen oder Fließkommawerte.

   "price": 1200.0
   

3. Booleans: Logische Werte true oder false.

   "inStock": true
   

JSON-Syntax

Container

1. Arrays: Geordnete Auflistungen in [ ].

   "items": ["Mountain Bike", "Helmet", "Gloves"]
   

2. Objects: Verschachtelte Schlüssel-Wert-Paare ({ }).

   {
     "name": "Helmet",
     "price": 49.99
   }
   

JSON-Syntax

{
  "product": {
    "id": 12345,
    "name": "Mountain Bike",
    "price": 1200.0,
    "currency": "USD",
    "sizes": [
      {
        "size": "M"
      },
      {
        "size": "L"
      }
    ]
  }
}

• Hinweis: Verschachtelte Strukturen sind typisch für komplexe JSON-Dokumente, wie sie in APIs genutzt werden (z. B. Produktdetails).

HTTP: Definition & Konzept

Was ist HTTP?

Das Hypertext Transfer Protocol (HTTP) ist das Kommunikationsprotokoll des World Wide Web. Es regelt, wie Nachrichten zwischen Client und Server ausgetauscht werden.^[3]

Aufbau einer HTTP-Kommunikation

Client (Browser)                        Server (API)
      |                                      |
      |  -- HTTP Request (GET /products) --> |
      |                                      |
      |  <-- HTTP Response (200 OK + JSON) - |
      |                                      |

• Request: Methode + URL + Header + (optional) Body
• Response: Statuscode + Header + Body (z. B. JSON-Daten)

HTTP GET im Browser

Übung: Erste API-Anfrage

1. Öffnen Sie Ihren Browser und navigieren Sie zu:
   https://dummyjson.com/products/1
2. Sie sehen die JSON-Antwort direkt im Browser – das ist ein HTTP GET!

Mit den Browser Developer Tools

1. Drücken Sie F12 (oder Rechtsklick → „Untersuchen")
2. Wechseln Sie zum Tab Netzwerk (Network)
3. Laden Sie die Seite https://dummyjson.com/products neu
4. Klicken Sie auf die Anfrage und untersuchen Sie:
   • Request-Methode: GET
   • Status Code: 200 OK
   • Response Headers: Content-Type: application/json
   • Response Body: Die JSON-Daten der Produkte

HTTP-Statuscodes

Die wichtigsten Statuscodes im Überblick

REST-Prinzip 1: Client-Server

Trennung von Verantwortlichkeiten

• Client (z. B. Browser, App) kümmert sich um die Darstellung
• Server (z. B. API) kümmert sich um die Datenverarbeitung und -speicherung
• Beide können unabhängig voneinander weiterentwickelt werden

┌──────────────┐              ┌──────────────┐
│    Client    │  ← HTTP →    │    Server    │
│  (Browser)   │              │    (API)     │
│  Darstellung │              │  Daten/Logik │
└──────────────┘              └──────────────┘

Ein Webshop kann sein Frontend (App, Website) anpassen, ohne die Backend-API ändern zu müssen.

• geringere Entwicklungskosten
• höhere Flexibilität

REST-Prinzip 2: Zustandslosigkeit

Jede Anfrage steht für sich

• Der Server speichert keinen Zustand zwischen zwei Anfragen
• Jede Anfrage muss alle Informationen enthalten (z. B. Authentifizierung)
• Der Server „vergisst" den Client nach jeder Antwort

Analogie

Stellen Sie sich einen Schalter bei einer Behörde vor: Bei jedem Besuch müssen Sie Ihren Ausweis erneut vorzeigen – der Sachbearbeiter erinnert sich nicht an Sie.

Vorteile

• Skalierbarkeit: Anfragen können auf beliebig viele Server verteilt werden
• Ausfallsicherheit: Fällt ein Server aus, übernimmt ein anderer nahtlos

REST-Prinzip 3: Caching

Antworten zwischenspeichern

• Server kann Antworten als cachefähig markieren
• Client oder Zwischensysteme (z. B. Proxy) speichern die Antwort und liefern sie bei erneuter Anfrage ohne den Server zu kontaktieren

Beispiel

1. Anfrage:  GET /products/1  →  Server antwortet (200 OK, Cache: 60s)
2. Anfrage:  GET /products/1  →  Antwort kommt aus dem Cache (kein Server-Kontakt)
3. Nach 70s: GET /products/1  →  Server wird erneut kontaktiert

Caching reduziert Serverkosten und verbessert die Ladezeiten für Nutzer. Amazon stellte fest, dass 100ms langsamere Ladezeiten ca. 1 % Umsatzverlust bedeuten.^[5]

REST-Prinzip 4: Mehrschichtige Systeme

Architektur in Schichten

• Zwischen Client und Server können weitere Schichten liegen
• Der Client weiß nicht, ob er direkt mit dem Server oder über Zwischenschichten kommuniziert

Typische Zwischenschichten

Mehrschichtige Systeme ermöglichen Skalierung und Sicherheit, ohne dass der Client angepasst werden muss.

REST-Prinzip 3 & 4 bei Amazon

1. Öffnen Sie F12 → Tab Network
2. Setzen Sie das Häkchen „Disable cache"
3. Laden Sie https://www.amazon.de → notieren Sie:
   • Anzahl der Anfragen (unten in der Statusleiste)
   • Gesamte übertragene Datenmenge
   • Gesamte Ladezeit
4. Entfernen Sie das Häkchen „Disable cache"
5. Laden Sie die Seite erneut → vergleichen Sie:

   Der Großteil der Bilder, CSS- und JS-Dateien wird aus dem lokalen Cache geladen.

6. Klicken Sie auf eine Bild- oder CSS-Anfrage und untersuchen Sie die Response Headers:

   Amazon nutzt CDNs. Selbst wenn der Server in den USA steht, kommt die Antwort von einem Server in Ihrer Nähe (z.B. Frankfurt).