Übungsaufgaben zu REST-APIs und HTTP

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „REST-APIs und HTTP“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/rest-grundlagen
- https://oer-informatik.de/uml-sequenzdiagramm
- Stilbeispiel: https://oer-informatik.de/rest-api-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- REST-API
- HTTP
- CRUD
- HTTP-Methoden
- HTTP-Statuscodes
- Idempotenz
- URL
- JSON
- API-Sicherheit

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

• Abgrenzung (2 Punkte): Bei der Authentifizierung prüft der Server, wer die Anfrage sendet (hier: gültiger Token von kunde_id 7). Bei der Autorisierung prüft er, ob diese Person die gewünschte Aktion an genau dieser Ressource ausführen darf.
• Lücke (2 Punkte): Termin 41 gehört zu kunde_id 2. Der Server hat nur die Anmeldung geprüft, nicht, ob der Termin dem anfragenden Konto gehört. Wer die IDs einfach hochzählt, kann so Termine und Rahmennummern aller Kund*innen abrufen (Risiko API1). Die Antwort hätte 403 Forbidden oder 404 Not Found lauten müssen.

Je Mitschnitt 2 Punkte (1 Punkt Zuordnung, 1 Punkt Begründung):

• Mitschnitt 2 – API3: Das eigene Kundenobjekt darf geändert werden, die Eigenschaft rolle aber nicht. Der Server übernimmt alle mitgeschickten Felder ungeprüft; ein Kundenkonto macht sich so selbst zur Werkstattleitung. (API5 ist als Folge vertretbar, wenn begründet wird, dass das Konto danach Leitungsfunktionen nutzen kann.)
• Mitschnitt 3 – API2: Fehlversuche werden nicht begrenzt, ein Passwort lässt sich durch Ausprobieren erraten (Brute Force). (API4 ist mit Begründung ebenfalls vertretbar.)
• Mitschnitt 4 – API4: Eine einzige Anfrage darf beliebig viele Datensätze abrufen und bindet dabei so viel Rechenzeit und Bandbreite, dass der Dienst für alle langsamer wird.

Je beschriebener Maßnahme 2 Punkte, z. B.:

• Mitschnitt 2: Für jede Rolle festlegen, welche Felder geschrieben werden dürfen (Allowlist), und alle anderen Felder ablehnen (400 oder 403). Rollen nur über eine eigene Verwaltungsfunktion der Leitung vergeben.
• Mitschnitt 3: Fehlversuche je Konto und je IP-Adresse begrenzen (Rate Limiting), nach mehreren Fehlversuchen Wartezeiten erhöhen oder eine zusätzliche Prüfung verlangen, Fehlversuche protokollieren und auffällige Muster melden.
• Mitschnitt 4: Seitenaufteilung erzwingen (z. B. höchstens 100 Termine je Antwort mit limit und offset), den abfragbaren Zeitraum begrenzen und die Zahl der Anfragen je Client und Minute beschränken (429 Too Many Requests).

Empfehlung Header Authorization (1 Punkt). Begründung (2 Punkte): URLs samt Query-Parametern landen in Server- und Proxy-Logs, im Verlauf und gegebenenfalls in weitergegebenen Links; ein dort mitgelesener Token erlaubt den Zugriff auf das Konto. Der Header ist der vorgesehene Ort für Zugangsdaten und wird über HTTPS genauso verschlüsselt wie der Rest der Anfrage, aber nicht als Teil der Adresse gespeichert.

• Adresse 1 (1 Punkt): richtig; die Reihenfolge der Query-Parameter ist beliebig.
• Adresse 2 (2 Punkte): zwei Fehler. Der zweite Parameter wird mit & statt mit einem weiteren ? angehängt, und das Datum steht im falschen Format. Richtig: …/sessions?raum=A.104&datum=2027-03-13.
• Adresse 3 (1 Punkt): Das ? fehlt. Der Server deutet raum=A.104&datum=2027-03-13 als Teil des Pfads, also als eigene Ressource, die es nicht gibt. Richtig: …/sessions?raum=A.104&datum=2027-03-13.

• Begründung (2 Punkte): GET soll nur lesen und keine Daten verändern (safe). Ein Browser, ein Link-Vorschau-Dienst oder ein erneutes Laden könnte die Anfrage wiederholen und Sessions doppelt anlegen. Außerdem gehört die Aktion („neu“) nicht in den Pfad, und die Daten landen in Browserverlauf und Server-Logs.
• Stattdessen (1 Punkt): POST /api/v1/sessions mit den Daten der Session als JSON im Body, z. B. über eine Eingabemaske des Orga-Teams.

Je 1 Punkt:

• 200 OK – Klasse 2xx (Erfolg): Die Sessions wurden geliefert.
• 404 Not Found – Klasse 4xx (Fehler des Clients): Die angefragte Ressource gibt es unter dieser URL nicht.
• 503 Service Unavailable – Klasse 5xx (Fehler des Servers): Der Info-Server ist vorübergehend überlastet oder in Wartung.

Je 2 Punkte, z. B.: Die URL ist auf diesem Monitor falsch eingetragen (Tippfehler im Pfad, z. B. /api/v1/session statt /sessions, oder alte Version /api/v0/…); der Raum ist als eigene Ressource angesprochen (/sessions/B.012), die es nicht gibt; die Raumbezeichnung im Info-Server lautet anders (z. B. B012), und die API behandelt einen unbekannten Raum im Filter als nicht vorhandene Ressource (sauberer wäre 200 OK mit leerer Liste, vgl. Aufgabe 3.2 c); der Monitor ruft einen anderen Server auf (z. B. wegen eines veralteten DNS-Eintrags), auf dem der Endpunkt fehlt.

• „nicht über HTTPS“ (1 Punkt): trifft nicht zu. SOAP-Nachrichten werden meist per POST über HTTP bzw. HTTPS übertragen.
• „kein JSON“ (1 Punkt): trifft zu. SOAP-Nachrichten sind XML-Dokumente mit Envelope, Header und Body.
• Empfehlung (2 Punkte), z. B. REST: Die Monitore brauchen nur einen GET-Aufruf und einen JSON-Parser; die Antworten sind kleiner und lassen sich zwischenspeichern, weil sich der Sessionplan selten ändert. Eine begründete Entscheidung für SOAP ist ebenfalls richtig, z. B. wenn eine feste, maschinenlesbare Schnittstellenbeschreibung (WSDL) für ein anderes Programm gebraucht wird.

• „JSON über HTTP“ (1 Punkt): zu kurz gegriffen. JSON ist nur eine mögliche Repräsentation; REST ist ein Architekturstil mit mehreren Prinzipien, die über das Datenformat hinausgehen.
• „Eigener Endpunkt je Funktion“ (2 Punkte): trifft nicht zu. Jede Aktivität ist eine Ressource mit eindeutiger URI, z. B. /v1/aktivitaeten/5, die Liste ist /v1/aktivitaeten. Was geschehen soll, steckt in der einheitlichen Schnittstelle der HTTP-Methoden: POST /v1/aktivitaeten legt an, DELETE /v1/aktivitaeten/5 löscht. Verben gehören nicht in den Pfad.
• „Server merkt sich die Anmeldung“ (1 Punkt): trifft nicht zu. REST ist zustandslos: Jede Anfrage bringt alles mit, was der Server braucht, auch das Zugangstoken im Header. Dadurch kann jede Anfrage von einem beliebigen Server-Exemplar beantwortet werden.

Auch weitere Prinzipien (Client-Server-Trennung, Zwischenspeicherbarkeit, Hypermedia-Links) sind als Ergänzung richtig.

Nr. 1 ist REST-konform (Ressource im Plural, Filter als Query-Parameter, GET zum Lesen). Für Nr. 2 bis 5 je 2 Punkte (1 Punkt korrigierter Endpunkt, 0,5 Punkte Begründung, 0,5 Punkte CRUD-Operation):

Auch PUT /v1/aktivitaeten/3/teilnahmen/2 für Nr. 5 ist vertretbar (der Client kennt die URI der neuen Teilnahme).

PATCH /v1/aktivitaeten/5 HTTP/1.1
Host: api.letsmeet.example
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI1In0.c2lnbmF0dXI
Content-Type: application/json
Accept: application/json

{"maxTeilnehmende": 6}

• Ursache 401 (1 Punkt): Die Anfrage enthält keine Zugangsdaten. Der Server kann nicht feststellen, wer sie sendet, und lehnt sie ab, bevor er den Body überhaupt auswertet.
• Header Authorization (1 Punkt): überträgt das Token der angemeldeten Person (Kim Bauer); damit prüft der Server Identität und Berechtigung (nur die erstellende Person darf ändern).
• Header Content-Type: application/json (1 Punkt): teilt dem Server das Format des Bodys mit; die API verarbeitet JSON. Mit text/plain käme nach dem Anmelden als Nächstes 415 Unsupported Media Type. Accept gibt an, dass die App die Antwort als JSON erwartet.
• Body (1 Punkt): Nutzdaten als JSON mit genau dem Attribut, das sich ändern soll; die Zahl ohne Anführungszeichen.
• Startzeile (1 Punkt): bleibt unverändert richtig: Methode PATCH (Ressource teilweise ändern), Pfad /v1/aktivitaeten/5 (API-Version 1, Aktivität mit der ID 5) und Protokollversion.

• PUT ersetzt die Ressource vollständig durch die mitgesendete Repräsentation; der Body muss also alle Attribute der Aktivität enthalten (Titel, Beschreibung, Treffpunkt, Beginn, Dauer …). (1 Punkt)

• PATCH ändert die Ressource teilweise; der Body enthält nur die zu ändernden Attribute. (1 Punkt)

• Mit PUT und dem Body {"maxTeilnehmende": 6} würden alle übrigen Attribute fehlen: Je nach Umsetzung lehnt der Server die Anfrage ab (z. B. 400 Bad Request, weil Pflichtfelder fehlen), oder er setzt die fehlenden Attribute auf leer bzw. Standardwerte – Titel, Treffpunkt und Beginn gingen verloren. (1 Punkt)

• Idempotent ist eine Anfrage, wenn sie mehrfach ausgeführt denselben Zustand auf dem Server hinterlässt wie einmal ausgeführt. (1 Punkt)

• Die Anfrage aus c) setzt die Höchstzahl auf den festen Wert 6. Ein zweites Mal ändert nichts mehr – sie wirkt idempotent. (1 Punkt) Hinweis: PATCH ist laut Standard nicht grundsätzlich idempotent (z. B. bei „erhöhe um 1“); PUT, GET und DELETE sind es immer.

• POST ist nicht idempotent: Jede Anfrage legt eine neue Ressource an. Eine doppelt gesendete Anmeldung könnte zwei Teilnahmen erzeugen und einen weiteren Platz belegen. Der Server muss das verhindern, etwa durch eine Prüfung auf bestehende Teilnahme (Antwort 409 Conflict). (1 Punkt)

Zuordnung je Zeile 1 Punkt:

204 und 405 werden nicht benötigt.

Erkennen (2 Punkte): An der ersten Ziffer. Codes der Klasse 4xx (hier 400, 401, 403, 404, 409) bedeuten, dass die Anfrage fehlerhaft oder unzulässig ist; die App muss sie ändern, eine unveränderte Wiederholung hilft nicht. Codes der Klasse 5xx (hier 500) bedeuten, dass die Anfrage in Ordnung war, der Server sie aber nicht bearbeiten konnte; eine spätere Wiederholung kann gelingen. 2xx steht für Erfolg.

• Endpunkt (1 Punkt): Schema https, Host api.ratzfahrt.example und Pfad /v1/monitor/eintraege (API-Version 1, Ressource „Einträge für die Monitoranzeige“) bestimmen, welcher Server und welcher Endpunkt die Anfrage bearbeitet.
• Filter (1 Punkt): Der Query-Teil nach dem ? mit den durch & getrennten Parametern haltepunkt=1, richtung=zur-schule, datum=2026-10-19 und max=10 schränkt die Auswahl ein bzw. begrenzt die Zahl der Einträge.
• Begründung (1 Punkt): Der Pfad bezeichnet eine Ressource, hier die Sammlung der Einträge. Haltepunkt, Richtung, Datum und Höchstzahl sind wahlweise kombinierbare Filter auf diese Sammlung, keine eigenen Ressourcen. Als Query-Parameter können sie fehlen oder in beliebiger Reihenfolge stehen, ohne dass für jede Kombination ein eigener Pfad nötig ist.

Je Bestandteil 1 Punkt:

• Statuszeile HTTP/1.1 200 OK: Protokollversion und Statuscode; 200 bedeutet, dass die Anfrage erfolgreich bearbeitet wurde.

• Header (Metainformationen): Content-Type: application/json gibt an, dass der Body JSON enthält; Cache-Control: max-age=60 erlaubt, die Antwort 60 Sekunden zwischenzuspeichern.

• Body (Nutzdaten): eine JSON-Liste mit einem Eintrag – das Angebot ab Gütersloh Hbf um 07:00 Uhr mit zwei freien Plätzen –, ohne Namen oder Pseudonyme, wie es die anonyme Anzeige verlangt.

• GET ist safe: Die Anfrage liest nur und verändert nichts. Wird eine gespeicherte Antwort wiederverwendet, statt den Server erneut zu fragen, fehlt keine Wirkung auf dem Server – Antworten auf GET sind daher grundsätzlich zwischenspeicherbar (cacheable). (1 Punkt)

• Die Anzeige auf den Fluren muss nicht sekundengenau sein; eine höchstens 60 Sekunden alte Liste reicht. Der Cache entlastet Server und Netz, weil vier Monitore nicht ständig dieselben Daten abrufen. (1 Punkt)

https://api.ratzfahrt.example/v1/monitor/eintraege?haltepunkt=4&richtung=nach-hause&datum=2026-10-22&max=5

1 Punkt für den Pfad mit Version und Endpunkt (/v1/monitor/eintraege), 1 Punkt für die vier Parameter mit richtigen Werten, 1 Punkt für die Syntax (? vor dem ersten, & zwischen den Parametern, keine Leerzeichen).

Gibt es keine passenden Einträge, antwortet der Server mit 200 OK und einer leeren Liste [] – nicht mit 404, denn die Ressource „Einträge“ existiert, sie ist nur leer.

Je Anfrage 1 Punkt, Begründung 2 Punkte:

1. PATCH /v1/angebote/1 mit {"freiePlaetze": 1} – nur ein Attribut ändert sich (auch PUT mit allen Daten des Angebots ist richtig).
2. PATCH /v1/angebote/1 mit {"status": "abgesagt"}
3. OPTIONS /v1/angebote – die Antwort nennt im Header Allow die erlaubten Methoden.

Begründung: Mit DELETE wäre das Angebot verschwunden. Die Mitfahrenden, die schon zugesagt haben, sehen dann nur noch eine Fehlermeldung statt des Hinweises „abgesagt“ und können nicht gezielt benachrichtigt werden. Gelöscht wird erst später nach der Löschregel.

POST /v1/angebote HTTP/1.1
Host: api.ratzfahrt.example
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiIxIn0.c2lnbmF0dXI
Content-Type: application/json
Accept: application/json

{"haltepunktId": 1, "richtung": "zur Schule", "datum": "2026-10-21", "abfahrt": "07:00", "freiePlaetze": 2, "kostenbeitragEur": 1.80, "fahrzeugId": 1}

• Startzeile mit POST auf die Sammlung /v1/angebote (1 Punkt)

• Header Content-Type: application/json und Authorization mit dem Token aus dem Single Sign-on (1 Punkt); Host und Accept sind sinnvoll, werden aber nicht gefordert.

• Body als gültiges JSON mit allen Angaben in passenden Datentypen (Zahlen ohne Anführungszeichen, Datum im Format JJJJ-MM-TT) (2 Punkte)

• Statuscode 201 Created, im Header Location die URI des neuen Angebots, z. B. /v1/angebote/8 (1 Punkt)

Wer fährt, steht nicht im Body: Der Server entnimmt die fahrende Person dem Token, sonst könnte jede*r Angebote im Namen anderer anlegen. Ergänzend: Haltepunkt 1 liegt 18,6 km von der Schule entfernt; bei höchstens 0,10 € je km liegt der Kostenbeitrag mit 1,80 € unter der Obergrenze von 18,6 km · 0,10 €/km = 1,86 €.

• Ursache (2 Punkte): 405 Method Not Allowed heißt, dass die Ressource existiert, aber mit einer Methode angesprochen wird, die der Server für sie nicht erlaubt. Zeile 11 verwendet GET (nur lesen), laut Dokumentation muss der Status mit PUT gesendet werden.

• Korrektur Zeile 11 (1 Punkt):

11      antwort = requests.put(url, json=daten, timeout=5)

Je Mangel 2 Punkte (1 Punkt Identifizieren mit Begründung, 1 Punkt Korrektur); zwei der folgenden:

• Zeile 4: http statt https – die Verbindung ist unverschlüsselt, der Schlüssel könnte im Schulnetz mitgelesen werden; die API erlaubt nur HTTPS.

  4   API = "https://api.ratzfahrt.example/v1"

• Zeile 10: Der API-Schlüssel steht als Query-Parameter in der URL. Laut Dokumentation gehört er in den Header X-API-Key; in der URL landet er außerdem in Server- und Proxy-Logs.

  10      url = API + "/monitore/" + str(MONITOR_ID) + "/status"
  11      antwort = requests.put(url, json=daten, headers={"X-API-Key": SCHLUESSEL}, timeout=5)

• Zeile 12: Bei Erfolg antwortet der Server mit 204, nicht mit 200. Das Skript würde also auch nach der Korrektur jede erfolgreiche Meldung als Fehler ausgeben.

  12      if antwort.status_code != 204:

  (Auch if not antwort.ok: – alle Codes unter 400 gelten als Erfolg – ist richtig.)

• Zeilen 11 und 16: Ist das Backend nicht erreichbar oder antwortet es nicht innerhalb von 5 Sekunden, löst requests eine Ausnahme aus (z. B. ConnectionError, Timeout). Sie wird nicht abgefangen, das Skript bricht ab und meldet danach gar keinen Status mehr.

  15  while True:
  16      try:
  17          melde_status(100)
  18      except requests.exceptions.RequestException as fehler:
  19          print("Statusmeldung fehlgeschlagen:", fehler)
  20      time.sleep(60)

• Beurteilung (2 Punkte): 410 Gone sagt genauer, dass es die Ressource gab und sie dauerhaft entfernt wurde; ein 404 lässt offen, ob die URL je gültig war. Damit kann die App „Dieses Angebot wurde gelöscht“ statt einer allgemeinen Fehlermeldung anzeigen. Dafür muss sich der Server aber merken, welche IDs gelöscht wurden. Ist das nicht gewünscht (Datensparsamkeit, Aufwand), ist 404 ebenfalls korrekt.
• Umgang in der App (1 Punkt): eine verständliche Meldung zeigen und den veralteten Eintrag aus der lokal zwischengespeicherten Übersicht entfernen bzw. die Übersicht neu laden, statt die Anfrage zu wiederholen.