Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Anwendungsentwicklung und Softwarequalität – Webschnittstellen als Verträge gestalten

QR-Code

Anwendungsentwicklung und Softwarequalität – Webschnittstellen als Verträge gestalten

Zielgruppe: Ausbildung Fachinformatik – Anwendungsentwicklung

Ausbildungsfall: Eine fiktive Geräteausleihe erhält eine verlässliche Webschnittstelle.

Lernziel: Du kannst HTTP-Anfragen und Antworten erklären, JSON-Datenverträge festlegen, Fehler behandeln und Schnittstellen lokal testen.

Voraussetzungen: Python 3, Texteditor, Grundkenntnisse in Programmierung.

Arbeitsweise: Kurze Lerneinheiten, Schaubilder, Videos, lokale Experimente, gestufte Hilfen und begründetes Feedback.

Einleitung

Eine Web-API verbindet Programme über definierte Regeln. Ein Schnittstellenvertrag legt fest, welche Anfragen erlaubt sind, welche Daten gesendet werden und welche Antworten zu erwarten sind.

Leitfrage: Wie bleibt eine Anwendung funktionsfähig, wenn sich ihr Server weiterentwickelt?

Web-API mit JSON-Antwort. Quelle: Wikimedia Commons, I.hate.spam.mail.here, CC0 1.0.

Deine Lernroute

Einheit	Schwerpunkt	Richtwert
Einstieg	Client und Server	5 Minuten
Anfrage	Methode, Pfad und Header	8 Minuten
Antwort	Statuscode und JSON	8 Minuten
Vertrag	Felder, Typen und Validierung	10 Minuten
Labor	Lokale API programmieren	12 Minuten
Test	Verträge automatisch prüfen	10 Minuten
Qualität	Änderungen sicher gestalten	8 Minuten

Ausbildungsfall: Die Geräteausleihe

Dein Ausbildungsbetrieb entwickelt eine kleine Anwendung für die Ausleihe von Schulungsgeräten.

Eine Oberfläche soll Geräte anzeigen und Ausleihanfragen anlegen. Das Backend liefert JSON-Daten.

Alle Geräte, Ausleihen und Kennungen im Kurs sind erfunden.

AUSLEIH-APP               LOKALE API
+--------------+          +-----------------+
| Oberfläche   |--GET---->| Gerät abrufen   |
|              |<--200----| JSON senden     |
|              |          |                 |
| Ausleihwunsch|--POST--->| Daten prüfen    |
|              |<--201----| Ausleihe anlegen|
+--------------+          +-----------------+

        Nur 127.0.0.1

Der vereinbarte Vertrag

Methode	Pfad	Bedeutung	Antwort
GET	/api/v1/geraete/G-17	Gerät abrufen	200
GET	/api/v1/ausleihen/A-1	Angelegte Ausleihe abrufen	200
POST	/api/v1/ausleihen	Ausleihanfrage erzeugen	201
GET	Unbekannter Pfad	Ressource fehlt	404
POST	Ungültiges JSON	Nachricht nicht lesbar	400
POST	Falscher JSON-Datentyp	Datenregel verletzt	422
POST	Falscher Medientyp	Format nicht unterstützt	415

Wichtig: Die Kennung A-1 entsteht erst nach einer erfolgreichen Anlage. Nach einem Neustart beginnt der lokale Beispieldienst wieder mit leerem Speicher.

Lerneinheit 1: Client, Server und HTTP

Client-Server-Modell. Quelle: Wikimedia Commons, Dew1978, CC BY-SA 4.0. Die Abbildung zeigt ein Node.js-Beispiel; das Kommunikationsprinzip gilt auch für unser Python-Labor.

Client sendet eine Anfrage.

Server verarbeitet sie und liefert eine Antwort.

HTTP definiert die Kommunikation.

API beschreibt, welche Funktionen und Daten nutzbar sind.

Client           HTTP             Server
  |                                |
  |---------- Anfrage ------------>|
  |                                |
  |<--------- Antwort -------------|
  |                                |

Basisfrage: Warum muss die Oberfläche wissen, in welchem Format der Server antwortet?

Feedback: Ohne vereinbartes Format kann der Client Felder und Datentypen nicht zuverlässig interpretieren.

Lerneinheit 2: Eine Anfrage lesen

Darstellung einer HTTP-Anfrage und Antwort. Quelle: Wikimedia Commons, Sébastien Santoro und Kulandru mor, gemeinfrei. Das historische Telnet-Beispiel wird hier nur betrachtet und nicht nachgebaut.

Aufbau einer Anfrage

GET /api/v1/geraete/G-17 HTTP/1.1
Host: 127.0.0.1:8765
Accept: application/json

Teil	Bedeutung
GET	HTTP-Methode
/api/v1/geraete/G-17	Ressourcenpfad
HTTP/1.1	HTTP-Version der dargestellten Anfrage
Host	Zielhost der Anfrage
Accept	Gewünschtes Antwortformat

GET dient dem Abrufen einer Repräsentation. Ein GET-Aufruf soll keine beabsichtigte Zustandsänderung auslösen.

POST übermittelt Daten zur Verarbeitung und kann neue Ressourcen erzeugen.

Mini-Aufgabe: Welche Methode passt?

Situation	Methode
Gerätedaten anzeigen	GET
Ausleihanfrage anlegen	POST

Feedback: GET ist für das Lesen vorgesehen. Die neue Ausleihanfrage wird durch POST erzeugt.

Lerneinheit 3: Antworten verstehen

Eine HTTP-Antwort enthält einen Statuscode, Header und gegebenenfalls einen Nachrichtenkörper.

201 Created
Content-Type: application/json
Location: /api/v1/ausleihen/A-1

{
  "id": "A-1",
  "geraet_id": "G-17",
  "tage": 3,
  "status": "angefragt"
}

Statuscodes als Entscheidungshilfe

                HTTP-ANTWORT
                     |
          +----------+----------+
          |          |          |
         2xx        4xx        5xx
        Erfolg   Clientfehler Serverfehler
          |          |          |
       200/201    400/404    z.B. 500
                  415/422

Status	Bedeutung	Beispiel
200	Erfolgreiche Verarbeitung	Gerät gefunden
201	Ressource erstellt	Ausleihe angelegt
400	Fehlerhafte Anfrage	JSON-Syntax ungültig
404	Ressource nicht gefunden	Unbekannte Gerätekennung
415	Medientyp nicht unterstützt	text/plain statt JSON
422	Inhalt nicht verarbeitbar	tage als Zeichenfolge
500	Interner Serverfehler	Unerwarteter Serverfehler

Merke: Statuscodes sind Teil des Vertrags. Der Client muss passende Reaktionen auf Erfolgs- und Fehlerantworten vorsehen.

Optionales Vertiefungsvideo: „HTTP-Statuscodes: Alle benutzen sie falsch?!“, the native web GmbH, 24.04.2022. Die Lizenz bleibt beim jeweiligen Rechteinhaber; die Einbettung erfolgt über YouTube.

Lerneinheit 4: JSON und stabile Datenformate

Beispiel einer Datenstruktur. Quelle: Wikimedia Commons, Frap, CC0 1.0.

JSON stellt strukturierte Daten dar.

{
  "id": "G-17",
  "typ": "Beamer",
  "max_tage": 14
}

id ist eine Zeichenfolge.

typ ist eine Zeichenfolge.

max_tage ist eine Zahl.

Die Namen, Typen und Bedeutungen dieser Felder gehören zum API-Vertrag.

Optionales Lernvideo: „Lerne JSON in 7 Minuten!“, Dev Planet Germany, 23.03.2022. Rechte beim Videoanbieter.

JSON und XML vergleichen

Vergleich strukturierter Datenformate. Quelle: Wikimedia Commons, Diego Mariano, CC BY-SA 4.0.

JSON und XML können strukturierte Daten transportieren. Entscheidend ist, dass sich beide Seiten auf ein Format und dessen Struktur einigen.

Der JSON-Vertrag unserer Ausleihe

{
  "geraet_id": "G-17",
  "tage": 3
}

Feld	Typ	Regel
geraet_id	String	Im Labor genau G-17
tage	Integer	Ganze Zahl von 1 bis 14

Das sind Pflichtfelder. Weitere Eingabefelder akzeptiert das Labor zunächst nicht.

Schema zur Dokumentation

Dieses JSON Schema beschreibt den erwarteten Anfragekörper:

{
  "type": "object",
  "required": ["geraet_id", "tage"],
  "additionalProperties": false,
  "properties": {
    "geraet_id": {
      "const": "G-17"
    },
    "tage": {
      "type": "integer",
      "minimum": 1,
      "maximum": 14
    }
  }
}

Hinweis: Das Python-Labor prüft diese Regeln direkt im Programm. Es benötigt keinen externen Schema-Validator.

Eine vollständige API-Dokumentation könnte zusätzlich mit OpenAPI Methoden, Pfade, Anfragen und Antworten beschreiben.

Lerneinheit 5: Das lokale API-Labor

Sicherheitsregel: Du verwendest ausschließlich deinen eigenen Rechner oder eine ausdrücklich freigegebene Übungsumgebung.

Unser Labor bindet den Server nur an die IPv4-Loopback-Adresse 127.0.0.1. Es verwendet weder Internet-APIs noch echte Geräte, Zugangsdaten oder Kundendaten.

Python 3 erforderlich; keine zusätzlichen Pakete.

Nicht für den Produktivbetrieb: Pythons Modul http.server ist ein Lernwerkzeug und bietet keine vollständige Produktionsabsicherung.

Schritt 1: Labor-Datei erstellen

Erstelle eine Datei namens api_labor.py und kopiere diesen vollständig eigenständigen Python-Code hinein.

from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlsplit
import json

AUSLEIHEN = {}  # Nur im Arbeitsspeicher, fiktive Daten

class Labor(BaseHTTPRequestHandler):
    def antwort(self, status, daten, ort=None):
        roh = json.dumps(daten, ensure_ascii=False).encode("utf-8")
        self.send_response(status)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(roh)))
        self.send_header("Cache-Control", "no-store")
        if ort:
            self.send_header("Location", ort)
        self.end_headers()
        self.wfile.write(roh)

    def fehler(self, status, code, nachricht, feld=None):
        info = {"code": code, "nachricht": nachricht}
        if feld:
            info["feld"] = feld
        self.antwort(status, {"fehler": info})

    def do_GET(self):
        pfad = urlsplit(self.path).path
        if pfad == "/api/v1/geraete/G-17":
            self.antwort(200, {"id": "G-17", "typ": "Beamer",
                                "max_tage": 14})
        elif pfad.startswith("/api/v1/ausleihen/"):
            kennung = pfad.rsplit("/", 1)[-1]
            if kennung in AUSLEIHEN:
                self.antwort(200, AUSLEIHEN[kennung])
            else:
                self.fehler(404, "NICHT_GEFUNDEN",
                            "Ausleihe nicht vorhanden")
        else:
            self.fehler(404, "NICHT_GEFUNDEN",
                        "Ressource nicht vorhanden")

    def do_POST(self):
        if urlsplit(self.path).path != "/api/v1/ausleihen":
            return self.fehler(404, "NICHT_GEFUNDEN",
                               "Ressource nicht vorhanden")
        typ = self.headers.get("Content-Type", "").split(";")[0].strip()
        if typ.lower() != "application/json":
            return self.fehler(415, "MEDIENTYP",
                               "application/json erforderlich")
        try:
            laenge = int(self.headers.get("Content-Length", ""))
            if not 0 < laenge <= 2048:
                raise ValueError("Ungueltige Laenge")
            daten = json.loads(self.rfile.read(laenge).decode("utf-8"))
        except (ValueError, UnicodeError):
            return self.fehler(400, "JSON_UNGUELTIG",
                               "Kein gueltiges JSON")
        if type(daten) is not dict or set(daten) != {"geraet_id", "tage"}:
            return self.fehler(422, "VALIDIERUNG",
                               "Felder geraet_id und tage erforderlich",
                               "schema")
        if daten["geraet_id"] != "G-17":
            return self.fehler(422, "VALIDIERUNG",
                               "Unbekanntes Geraet", "geraet_id")
        if type(daten["tage"]) is not int or not 1 <= daten["tage"] <= 14:
            return self.fehler(422, "VALIDIERUNG",
                               "tage muss ganze Zahl von 1 bis 14 sein",
                               "tage")
        kennung = f"A-{len(AUSLEIHEN) + 1}"
        AUSLEIHEN[kennung] = {
            "id": kennung, "geraet_id": "G-17",
            "tage": daten["tage"], "status": "angefragt"
        }
        self.antwort(201, AUSLEIHEN[kennung],
                     f"/api/v1/ausleihen/{kennung}")

if __name__ == "__main__":
    print("Nur lokal: http://127.0.0.1:8765")
    HTTPServer(("127.0.0.1", 8765), Labor).serve_forever()

Schritt 2: Starten

Öffne im Projektordner ein Terminal.

python api_labor.py

Je nach Betriebssystem lautet der Befehl auch python3 api_labor.py oder py api_labor.py.

Öffne anschließend im eigenen Browser:

http://127.0.0.1:8765/api/v1/geraete/G-17

Erwartet wird:

{
  "id": "G-17",
  "typ": "Beamer",
  "max_tage": 14
}

Stoppen: Im Server-Terminal Strg+C drücken.

Grenze des Labors: Die Ausleihen existieren nur im Arbeitsspeicher. Nach einem Neustart sind sie gelöscht.

Lerneinheit 6: Vertrags- und Fehlertests

Ein Vertragstest überprüft, ob die API vereinbarte Antworten liefert.

Testpyramide. Quelle: Wikimedia Commons, Abbe98, CC BY-SA 4.0.

Unser kleines Labor verwendet HTTP-Tests gegen einen lokalen Testserver. Sie prüfen Statuscodes, Datenfelder und die Erreichbarkeit neu angelegter Ausleihen.

Lokale Testumgebung: Automatisch und interaktiv

Erstelle im selben Ordner die Datei test_labor.py.

from urllib.request import Request, urlopen
from urllib.error import HTTPError
import json
import sys

BASIS = "http://127.0.0.1:8765"  # Nie externe Ziele

def senden(pfad, methode="GET", inhalt=None, typ="application/json"):
    daten = inhalt.encode("utf-8") if inhalt is not None else None
    kopf = {"Content-Type": typ} if inhalt is not None else {}
    anfrage = Request(BASIS + pfad, data=daten,
                      headers=kopf, method=methode)
    try:
        with urlopen(anfrage, timeout=3) as antwort:
            return antwort.status, dict(antwort.headers), json.load(antwort)
    except HTTPError as fehler:
        return fehler.code, dict(fehler.headers), json.loads(
            fehler.read().decode("utf-8"))

def test(name, pfad, methode, inhalt, erwartet, prueffeld):
    code, kopf, daten = senden(pfad, methode, inhalt)
    assert code == erwartet and prueffeld in daten, name
    print("OK:", name, "->", code)
    return kopf, daten

if "--interaktiv" in sys.argv:
    auswahl = {
        "1": ("/api/v1/geraete/G-17", "GET", None),
        "2": ("/api/v1/geraete/X-99", "GET", None),
        "3": ("/api/v1/ausleihen", "POST",
              '{"geraet_id":"G-17","tage":3}'),
        "4": ("/api/v1/ausleihen", "POST",
              '{"geraet_id":"G-17","tage":"3"}')
    }
    while True:
        wahl = input("1 Lesen | 2 Fehlt | 3 Anlegen | 4 Fehler | 0 Ende: ")
        if wahl == "0":
            break
        if wahl in auswahl:
            code, kopf, daten = senden(*auswahl[wahl])
            print("Status:", code, "JSON:", json.dumps(daten, indent=2))
        else:
            print("Bitte 0 bis 4 wählen.")
else:
    test("Gerät", "/api/v1/geraete/G-17", "GET", None, 200, "id")
    test("Fehlende Ressource", "/api/v1/geraete/X-99",
         "GET", None, 404, "fehler")
    kopf, daten = test("Ausleihe erzeugen", "/api/v1/ausleihen",
         "POST", '{"geraet_id":"G-17","tage":3}', 201, "id")
    pfad = kopf["Location"]
    assert pfad == "/api/v1/ausleihen/" + daten["id"]
    test("Ausleihe wieder lesen", pfad, "GET", None, 200, "id")
    test("Falscher Typ", "/api/v1/ausleihen", "POST",
         '{"geraet_id":"G-17","tage":"3"}', 422, "fehler")
    test("Defektes JSON", "/api/v1/ausleihen",
         "POST", '{"geraet_id":', 400, "fehler")
    code, _, daten = senden("/api/v1/ausleihen", "POST",
                             '{"tage":3}', "text/plain")
    assert code == 415 and "fehler" in daten
    print("OK: Falscher Medientyp -> 415")
    print("7 Vertragstests erfolgreich.")

Testdurchführung

Terminal A: Server starten.

python api_labor.py

Terminal B: Automatische Tests ausführen.

python test_labor.py

Für das interaktive Menü:

python test_labor.py --interaktiv

Beide Programme dürfen nur im freigegebenen lokalen Labor ausgeführt werden.

Erwartete Testergebnisse

Test	Erwartung	Begründung
Gerät lesen	200	Bekannte Ressource vorhanden
Unbekanntes Gerät lesen	404	Ressource fehlt
Ausleihe erzeugen	201	Neue Ressource angelegt
Ausleihe erneut lesen	200	Ressource erreichbar
tage als Text	422	Datentyp verletzt Vertrag
Beschädigtes JSON	400	Syntax nicht lesbar
text/plain senden	415	Medientyp nicht unterstützt

Das Programm meldet erfolgreiche Tests oder bricht bei einer verletzten Erwartung mit einer Fehlermeldung ab. Die Ergebnisse hängen vom tatsächlichen Programmlauf ab.

Testdaten und Datenfluss visualisieren

POST mit gültigen Daten
        |
        v
Prüfe Content-Type
        |
        v
Parse JSON
        |
        v
Prüfe Felder und Typen
        |
    +---+---+
    |       |
 gültig   ungültig
    |       |
   201     422
    |
 Location-Header
    |
    v
GET der neuen Ausleihe
    |
   200

Unterscheide: Bei ungültigem JSON entsteht hier ein Fehler 400. Ein falscher Medientyp führt zu 415, bevor der Inhalt geprüft wird.

Lerneinheit 7: Stabile Schnittstellen gestalten

Eine API ist ein Vertrag zwischen Anbieter und Verbraucher.

Die Änderung eines Feldnamens kann einen bestehenden Client beschädigen, obwohl der Server technisch weiterhin funktioniert.

Kompatibilität verstehen

Änderung	Bewertung	Grund
id entfernen	Vertragsbruch	Bisherige Clients benötigen das Feld
tage von Zahl zu Text ändern	Vertragsbruch	Datentyp verändert
geraet_id umbenennen	Vertragsbruch	Bestehende Anfragen funktionieren nicht
Optionales Antwortfeld ergänzen	Häufig kompatibel	Wenn Clients zusätzliche Felder tolerieren
Neue Version v2 separat anbieten	Geordnete Migration	Alte Clients können v1 weiterverwenden

Versionspfade wie /api/v1/ und /api/v2/ sind eine mögliche Strategie. Sie ersetzen keine sorgfältige Dokumentation und keine Regressionstests.

Fehler sind ebenfalls Teil des Vertrags

Unser Labor verwendet für Fehler eine einheitliche Struktur.

{
  "fehler": {
    "code": "VALIDIERUNG",
    "nachricht": "tage muss ganze Zahl von 1 bis 14 sein",
    "feld": "tage"
  }
}

So kann ein Client Fehler nachvollziehbar anzeigen. In realen Anwendungen sollten Fehlermeldungen keine Zugangsdaten oder internen Geheimnisse offenlegen.

Merke: Eine gute Schnittstelle ist nicht nur bei Erfolg vorhersehbar, sondern auch bei Fehlern.

Gestufte Hilfen

Nutze immer nur so viel Hilfe wie nötig.

Hilfestufe 1: Hinweis

Prüfe zuerst Methode, Pfad, Statuscode und JSON-Datentyp. Ein Wert in Anführungszeichen ist eine Zeichenfolge.

Hilfestufe 2: Teillösung

Für eine erfolgreiche Ausleihanfrage benötigst du POST, den Pfad /api/v1/ausleihen, den Medientyp application/json und einen ganzzahligen Wert für tage.

Hilfestufe 3: Musterkontrolle

POST /api/v1/ausleihen
Content-Type: application/json

{"geraet_id":"G-17","tage":3}

Erwartung:
201 Created
Location: /api/v1/ausleihen/A-1

Begründung: Der Anfragekörper erfüllt den festgelegten Vertrag. Beim ersten erfolgreichen POST nach dem Serverstart wird A-1 angelegt.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was beschreibt ein API-Vertrag? (Pfade Methoden Datenformate und Antworten) (!Nur das Aussehen der Benutzeroberfläche) (!Nur die Programmiersprache) (!Nur die Hardware des Servers)

Wofür dient GET normalerweise? (Zum Abrufen einer Ressource) (!Zum verpflichtenden Anlegen einer Ressource) (!Zum Ändern eines Passwortes) (!Zum Löschen aller Daten)

Welcher Medientyp kennzeichnet JSON? (application/json) (!text/html) (!image/png) (!application/pdf)

Welcher Status passt zur erfolgreichen Anlage einer neuen Ausleihe? (201 Created) (!404 Not Found) (!500 Internal Server Error) (!415 Unsupported Media Type)

Welcher Status passt zu einer nicht gefundenen Ressource? (404 Not Found) (!200 OK) (!201 Created) (!204 No Content)

Welchen Status verwendet unser Labor für fehlerhafte JSON-Syntax? (400 Bad Request) (!201 Created) (!200 OK) (!301 Moved Permanently)

Welchen Status liefert unser Labor bei tage als Zeichenfolge? (422 Unprocessable Content) (!201 Created) (!404 Not Found) (!500 Internal Server Error)

Welcher Wert erfüllt den Vertrag für das Feld tage? (3 als ganze Zahl) (!Die Zeichenfolge drei) (!Der Wahrheitswert true) (!Der Wert null)

Was schützt bestehende Clients bei API-Änderungen? (Regelmäßige Vertragstests) (!Unangekündigtes Umbenennen der Felder) (!Entfernen aller Fehlermeldungen) (!Wechselnde Datentypen ohne Dokumentation)

Welche Adresse verwendet das lokale API-Labor? (127.0.0.1) (!Eine fremde Firmenadresse) (!Eine beliebige öffentliche IP-Adresse) (!Eine Produktionsdatenbank im Internet)

Memory

Finde die passenden Begriffspaare.

GET	Ressource abrufen
POST	Neue Ressource erzeugen
Header	Zusatzinformation zur Nachricht
JSON	Strukturiertes Austauschformat
Statuscode	Ergebnis der Anfrage
Schema	Vereinbarte Datenstruktur
Loopback	Lokale Netzwerkadresse
Regressionstest	Prüfung gegen unbeabsichtigte Änderungen

Drag and Drop

Ordne die richtigen Begriffe zu.	Bedeutung
Client	Sendet eine Anfrage
Server	Liefert die Antwort
Pfad	Adressiert eine Ressource
Validierung	Überprüft Datenregeln
Versionierung	Ermöglicht getrennte Schnittstellenstände

Kreuzworträtsel

Header	Wie heißen die Zusatzinformationen einer HTTP-Nachricht?
Anfrage	Was sendet ein Client an den Server?
Antwort	Was liefert ein Server als Reaktion?
Schema	Wie nennt man eine formale Beschreibung der Datenstruktur?
Vertrag	Wie nennt man die verbindliche Vereinbarung zwischen API und Client?
Validierung	Wie heißt die Prüfung von Daten gegen Regeln?

LearningApps

Die folgende externe Suche bietet gegebenenfalls zusätzliche Übungen. Sie ist kein Bestandteil des lokalen API-Testlabors. Externe Inhalte nur nach Freigabe öffnen.

Lückentext

Bei einer HTTP-Kommunikation sendet der

eine Anfrage.

Die Antwort auf eine HTTP-Anfrage stammt vom

.

Zum Abrufen einer Ressource verwenden wir die Methode

.

Zum Anlegen der Ausleihanfrage nutzen wir

.

Das strukturierte Austauschformat unseres Labors heißt

.

Eine erfolgreiche Neuanlage wird mit dem Statuscode

bestätigt.

Für eine fehlende Ressource wird der Statuscode

verwendet.

Das Feld tage benötigt den JSON-Datentyp

.

Eine formale Beschreibung der Datenregeln heißt

.

Unsere Übungen erreichen ausschließlich die Adresse

.

Offene Aufgaben

Die Aufgaben sind in Basis-, Anwendungs- und Transferniveau gegliedert. Arbeite nur mit den fiktiven Labor-Daten. Nutze bei Bedarf die gestuften Hilfen.

Leicht – Basisaufgaben

HTTP-Anfrage: Zeichne den Weg einer Anfrage von Client zu Server und zurück. Feedback: Beide Richtungen müssen erkennbar sein, weil HTTP aus Anfragen und Antworten besteht.
HTTP-Methoden: Ordne GET und POST den Tätigkeiten Lesen und Anlegen zu. Feedback: GET liest, POST kann eine neue Ressource erzeugen; so bleiben Zuständigkeiten nachvollziehbar.
JSON: Erstelle einen gültigen Anfragekörper für drei Ausleihtage. Feedback: tage muss eine Zahl sein, weil der Vertrag einen Integer fordert.
HTTP-Statuscode: Erstelle vier Karten zu 200, 201, 404 und 422. Feedback: Die Karten müssen Ursache und Bedeutung enthalten, weil ein Statuscode allein wenig über die fachliche Reaktion aussagt.

Standard – Anwendungsaufgaben

Lokaler Server: Starte das Labor und rufe das Beispielgerät im Browser ab. Feedback: Eine JSON-Antwort mit Status 200 zeigt, dass die Ressource lokal erreichbar ist.
Softwaretest: Führe die automatischen Vertragstests aus und dokumentiere die Ausgabe. Feedback: Status und Datenstruktur müssen geprüft werden, denn ein erfolgreicher HTTP-Status allein garantiert noch keine korrekte Antwort.
POST: Lege eine Ausleihanfrage an und rufe sie anschließend über den Location-Pfad ab. Feedback: Die Kombination aus 201, Location und anschließendem GET zeigt, dass die neue Ressource auffindbar ist.
Fehlerbehandlung: Vergleiche die Antworten auf ungültige JSON-Syntax und einen falschen tage-Datentyp. Feedback: 400 und 422 unterscheiden sich, weil Syntaxprüfung und inhaltliche Validierung unterschiedliche Fehlerklassen sind.

Schwer – Transferaufgaben

API-Kompatibilität: Entwirf ein neues optionales Antwortfeld und beurteile seine Verträglichkeit. Feedback: Es ist nur dann in der Regel kompatibel, wenn bestehende Clients zusätzliche Felder akzeptieren.
Versionierung: Plane eine neue API-Version, in der tage durch einen anderen Pflichtparameter ersetzt wird. Feedback: Ein eigener Versionierungsweg ermöglicht eine Übergangsphase, weil alte Anfragen nicht unverändert zum neuen Vertrag passen.
JSON Schema: Erweitere die Vertragsdokumentation um einen zusätzlichen gültigen Wertebereich und zwei passende Negativtests. Feedback: Vertragsregeln und Testfälle müssen übereinstimmen, sonst kann die Implementierung falsche Daten akzeptieren.
Softwarequalität: Produziere ein kurzes Lernvideo oder eine Bildgeschichte, die einen Vertragsbruch und seine Reparatur erklärt. Feedback: Eine gute Darstellung zeigt Ursache, beobachteten Fehler, Test und Korrektur, weil Softwarequalität nachprüfbare Änderungen benötigt.

Rückmelde- und Bewertungskompass

Niveau	Erfüllt, wenn ...	Begründetes Verbesserungsfeedback
Basis	Methode, Status und Datenformat richtig erkannt	Ohne diese Zuordnung wird die Kommunikation falsch interpretiert.
Anwendung	Lokaler Test reproduzierbar und nachvollziehbar	Ein dokumentierter Test macht Fehler für andere überprüfbar.
Transfer	Veränderung samt Kompatibilitätsrisiko begründet	Softwarequalität zeigt sich daran, dass bestehende Verbraucher berücksichtigt werden.

Selbstkontrolle: Was war deine Erwartung? Was hast du beobachtet? Warum stimmen die Ergebnisse überein oder unterscheiden sie sich?

Lernkontrolle

Bearbeite die folgenden Transferfragen mit kurzen Begründungen.

Schnittstellenvertrag: Ein Frontend erwartet max_tage als Zahl. Das Backend liefert plötzlich Text. Erkläre die Auswirkungen und entwickle eine Migrationsstrategie.
Fehlerbehandlung: Zwei verschiedene Fehler werden beide mit Status 200 beantwortet. Beurteile, weshalb dies die Auswertung durch den Client erschwert, und schlage eine bessere Vertragsregel vor.
Teststrategie: Ein POST-Test prüft nur den Status 201. Begründe, welche zusätzlichen Vertragsmerkmale geprüft werden sollten.
Versionsverwaltung: Ein Team möchte einen Pflichtparameter ohne Vorwarnung umbenennen. Entwickle einen Ablauf, der bestehende Clients möglichst wenig beeinträchtigt.
Datenschutz: Ein Auszubildender möchte eine reale Kundendatenbank als Testquelle verwenden. Entwirf eine sichere Alternative mit fiktiven Daten.
Softwarequalität: Vergleiche manuelle API-Prüfung und automatisierte Vertragstests hinsichtlich Wiederholbarkeit, Fehlersuche und Wartbarkeit.

Lernnachweis

Für einen aussagekräftigen Lernnachweis dokumentierst du:

API-Dokumentation: Eine Vertragstabelle mit Methoden, Pfaden, erwarteten Statuscodes und Datenfeldern.
JSON Schema: Ein Schema mit Pflichtfeldern, Datentypen und Wertebereichen.
Softwaretest: Die tatsächlichen Ergebnisse der lokalen Vertragstests einschließlich eines Negativtests.
Fehleranalyse: Eine nachvollziehbare Erklärung für mindestens zwei unterschiedliche Fehlerantworten.
Kompatibilität: Einen Vorschlag zur sicheren Änderung oder Versionierung der Schnittstelle.
Datenschutz: Eine Bestätigung, dass ausschließlich freigegebene lokale Testumgebungen und fiktive Daten verwendet wurden.

Bewertung: Fachliche Richtigkeit, nachvollziehbare Tests, Transferleistung, begründete Entscheidungen und verantwortlicher Umgang mit Testumgebungen.

OERs zum Thema

Fachlich geprüfte Grundlagen und Originalquellen:

RFC 9110 – HTTP Semantics: Methoden, Header und Statuscodes.
RFC 8259 – JSON: Syntax und Datentypen.
MDN – HTTP Overview: Anfragen, Antworten und Client-Server-Prinzip.
MDN – HTTP Status Codes: Einordnung der Antwortcodes.
JSON Schema – Objects: Pflichtfelder und Eigenschaften.
OpenAPI Specification 3.1.1: Formale Beschreibung von HTTP-Schnittstellen.
Python-Dokumentation – http.server: Lokale HTTP-Server und Sicherheitshinweise.

Medienrechte:

Die verwendeten Wikimedia-Commons-Abbildungen besitzen auf ihren verlinkten Dateiseiten ausgewiesene freie Lizenzen beziehungsweise Gemeinfreiheitskennzeichnungen. Namensnennung und Lizenzbedingungen der CC-BY-SA-Dateien müssen bei der Nachnutzung beachtet werden.

Die eingebundenen YouTube-Videos sind externe, optionale Lehrmedien und nicht automatisch offen lizenziert. Es erfolgt keine Erlaubnis zum Herunterladen oder Weiterverbreiten. Externe Video- und iFrame-Inhalte können beim Laden Browserdaten an ihre Anbieter übertragen. Im Unterricht nur entsprechend den geltenden Datenschutzvorgaben einsetzen; der vollständige lokale API-Lernpfad funktioniert ohne diese Dienste.

Wikipedia zur Vertiefung: