Aufgaben API
Zehn IHK-Aufgaben durch alle K51-Themen: API-Stile, HTTP-Methoden & Statuscodes, REST-URL-Design, AuthN/AuthZ, JWT, OAuth2, Versionierung, Rate Limiting, API-Testing. Mix aus Multiple-Choice, Mehrfachauswahl, Zuordnung, Reihenfolge und einer offenen Modellierungsaufgabe. Am Ende eine Note. Viel Erfolg!
Aufgabe 12 Punkte
API-Stil identifizieren
Eine Mobile-App soll mit einem Aufruf einen Nutzer mit seinen letzten 20 Posts, jeweils inklusive Anzahl der Kommentare, holen. Welcher API-Stil ist am besten geeignet?
SOAP – durch strenges WSDL ist die Anfrage sehr robust.
REST – mit drei aufeinanderfolgenden Aufrufen lässt sich das gut abbilden.
GraphQL – der Client wählt exakt die benötigten Felder und verschachtelte Daten in einer einzigen Anfrage.
Reines HTTP ohne Stil – das ist am flexibelsten.
Richtig. Genau für solche Szenarien (Mobile-App, verschachtelte Daten in einem Aufruf) wurde GraphQL entwickelt. Bei REST wären es 1 + N Aufrufe für die Posts, oder ein Sonder-Endpunkt. SOAP wäre für Mobile viel zu schwergewichtig. Vgl. L1.
Merke: REST ist Standard. SOAP für Enterprise / Banken. GraphQL bei flexiblen, verschachtelten Datenabfragen.
Aufgabe 23 Punkte
HTTP-Methoden zuordnen
Ordne jede Aktion der richtigen HTTP-Methode zu. Klick zuerst eine Methode unten, dann das passende Ziel:
GET
POST
PUT
PATCH
DELETE
Neuen User anlegen
User komplett ersetzen
Nur die E-Mail eines Users ändern
Alle User abrufen
User entfernen
Auswertung: POST anlegen, PUT komplett ersetzen, PATCH partielle Änderung, GET lesen, DELETE entfernen. Merke: PUT ersetzt alles (kompletter Datensatz im Body), PATCH nur die geänderten Felder. Vgl. L2.
Aufgabe 32 Punkte
Statuscode wählen
Ein angemeldeter Standard-User schickt:
DELETE /api/users/7. Die Aktion ist nur für Admins erlaubt. Welcher Statuscode ist korrekt?401 Unauthorized – der User darf nicht löschen.
403 Forbidden – der User ist angemeldet, hat aber nicht die Berechtigung.
404 Not Found – der Endpunkt wird verheimlicht.
405 Method Not Allowed – DELETE ist verboten.
Richtig. 401 würde bedeuten „Auth fehlt" – aber der User ist eingeloggt. 403 ist „eingeloggt, aber nicht berechtigt". 404 wäre eine bewusste Verschleierung – nicht standardkonform. 405 ist für nicht-unterstützte Methoden (z.B. DELETE auf
/static.html). Vgl. L4.
Merke: 401 = wer? 403 = was?
Aufgabe 43 Punkte
OAuth2 Authorization Code Flow ordnen
Bring die Schritte des OAuth2 Authorization Code Flow in die richtige Reihenfolge:
Korrekte Reihenfolge: 1. User klickt „Mit Google anmelden" → 2. Client leitet Browser zum Auth-Server weiter → 3. User loggt sich ein und gibt Consent → 4. Auth-Server gibt Authorization Code per Redirect zurück → 5. Backend tauscht Code + Client Secret direkt gegen Token → 6. Client nutzt Access Token bei der API. Vgl. L6.
Aufgabe 52 Punkte
JWT analysieren
Aus einem JWT wird der Payload decodiert:
{ "sub": "7", "name": "Anna", "role": "admin", "exp": 1715938000 }
Welche Aussage ist korrekt?
Der Payload ist verschlüsselt – nur der Server kann ihn lesen.
Der Payload ist nur Base64-kodiert; jeder kann ihn lesen. Schutz vor Manipulation kommt allein aus der Signatur.
Der Token ist gültig, weil er drei Teile hat – Signatur-Prüfung ist optional.
Das
exp-Feld muss in Millisekunden angegeben werden.
Richtig. JWTs sind nicht verschlüsselt, nur kodiert. Keine sensitiven Daten im Payload! Die Signatur (dritter Teil) schützt vor Manipulation – ohne Geheimnis kann sie niemand neu berechnen.
exp ist Unix-Timestamp in Sekunden, nicht Millisekunden. Vgl. L5.
Merke: Base64 ≠ Verschlüsselung. JWT-Header und Payload sind lesbar.
Aufgabe 63 Punkte
RESTful URLs erkennen
Welche URLs sind RESTful korrekt? Wähle alle zutreffenden:
✓
GET /api/v1/products?category=Bücher&page=2✓
POST /api/v1/getProductById/42✓
DELETE /api/v1/orders/42✓
GET /api/v1/users/7/orders✓
POST /api/v1/deleteOrder?orderId=42✓
GET /api/v1/Product/42 (Singular, Großbuchstabe)
Korrekt: Plural + Substantiv + Query-Parameter für Filter/Pagination (1), HTTP-Verb passt zur Aktion (3), verschachtelte Ressource sauber abgebildet (4).
Falsch: Verb in URL (2 + 5 → richtig wäre
Falsch: Verb in URL (2 + 5 → richtig wäre
GET /products/42 bzw. DELETE /orders/42). Singular + Großbuchstabe (6 → richtig wäre /products/42). Vgl. L3.
REST-Konvention: lowercase, Plural, Substantiv, Bindestriche statt Underscores.
Aufgabe 73 Punkte
Breaking Change erkennen
Welche der folgenden API-Änderungen ist KEINE Breaking Change?
Das Feld
created_at in createdAt umbenennen.Den Datentyp von
alter von Integer zu String ändern.Ein neues optionales Feld
avatar_url in der User-Antwort hinzufügen.Das Pflichtfeld
phone bei POST /users hinzufügen.
Richtig. Optionale Felder hinzufügen ist immer abwärtskompatibel – alte Clients ignorieren das einfach. Umbenennen, Datentyp ändern und neue Pflichtfelder sind Breaking Changes und erfordern eine neue Major-Version. Vgl. L7.
Faustregel: würde mein alter Client noch funktionieren? Ja → non-breaking. Nein → breaking.
Aufgabe 82 Punkte
Reaktion auf 429
Dein Client bekommt eine Antwort mit Statuscode
429 Too Many Requests und dem Header Retry-After: 30. Was ist das richtige Client-Verhalten?Sofort die Anfrage 5-mal hintereinander wiederholen – dann klappt mindestens eine.
Dem User einen Fehler anzeigen und nichts weiter tun.
30 Sekunden warten, dann erneut versuchen – mit Exponential Backoff bei erneutem 429.
Den Authorization-Header entfernen und es ohne Auth versuchen.
Richtig. Der
Retry-After-Header sagt dem Client, wann es Sinn macht erneut zu versuchen. Mehrfache sofortige Wiederholungen machen alles schlimmer. Exponential Backoff (1s, 2s, 4s, 8s ...) mit Jitter ist Best Practice für robuste Clients. Vgl. L8.
Aufgabe 93 Punkte
JWT-Sicherheit
Welche Praktiken bei JWT sind sicherheits-konform? Wähle alle zutreffenden:
✓Das
exp-Claim (Ablaufzeit) immer setzen.✓Das Passwort des Users in den Payload schreiben.
✓Den Algorithmus
none auf dem Server explizit ablehnen.✓Für Multi-Service-Architekturen RS256 (asymmetrisch) statt HS256 nutzen.
✓Den Token in der URL als Query-Parameter mitsenden.
✓Bei jedem Request die Signatur verifizieren.
Richtig sind: exp-Claim Pflicht, alg=none explizit ablehnen, RS256 bei Microservices, Signatur immer prüfen.
Falsch: Passwort im Payload (Base64 ist lesbar!), Token in URL (landet in Logs / History). Vgl. L5.
Falsch: Passwort im Payload (Base64 ist lesbar!), Token in URL (landet in Logs / History). Vgl. L5.
Aufgabe 105 Punkte
API-Architektur entwerfen
Du baust eine öffentliche REST-API für einen Buchladen mit folgenden Anforderungen:
Das System prüft, ob die wichtigsten Stichworte vorkommen:
- 3rd-Party-Entwickler integrieren sie in eigene Apps (per Login mit dem Buchladen-Account)
- Anonyme Nutzer dürfen Bücher suchen, aber nicht kaufen
- Login per E-Mail/Passwort, Sessions sollen kurzlebig sein
- Limit: max 100 Anfragen pro Minute für freie Konten
Das System prüft, ob die wichtigsten Stichworte vorkommen:
Mögliche Musterlösung: Für die Versionierung wähle ich URL-Versionierung mit
/api/v1/... – sichtbar, einfach zu debuggen, von allen Tools verstanden. Für die Authentifizierung nutze ich OAuth2 mit OpenID Connect, da Drittanbieter-Apps Zugriff brauchen ohne das Passwort zu kennen. Beim Login bekommt der Client einen kurzlebigen JWT-Access-Token (15 Min) und einen Refresh-Token (30 Tage). Geschützte Endpunkte prüfen den Token im Authorization: Bearer-Header. Fehlt der Token → 401 Unauthorized. Versucht ein User eine fremde Bestellung zu sehen → 403 Forbidden. Rate Limiting umsetzt mit Token-Bucket pro API-Key (100/min Free-Tier), Header X-RateLimit-Remaining in jeder Antwort, bei Überschreitung 429 Too Many Requests mit Retry-After-Header. Vgl. L7, L6, L8.
📊 Auswertung
Punkte
0
Prozent
0%
Note
–
Aufgaben gelöst
0/10
Verwandte Lektionen zum Wiederholen: L2 HTTP vertieft · L3 REST-Design · L5 JWT · L6 OAuth2 · L8 Rate Limiting
Nächste Kurse: K52 Testen & Testmanagement baut direkt auf L9 API-Testing auf. Für Sicherheit über APIs hinaus: K11 Secure Coding. Architektur-Gesamtsicht: K50 Softwarearchitektur.