Fragen und Antworten zum Thema REST-API (Leitfaden 2026)

REST-APIs machen die meisten Integrationen im Internet möglich. Egal, ob du dich für eine Backend-Position, eine Full-Stack-Stelle oder einen Job als Softwareentwickler bewirbst, du wirst wahrscheinlich Fragen zu REST-API-Design, HTTP-Methoden und Authentifizierungsmustern bekommen.

In diesem Leitfaden zeige ich dir, welche Fragen Interviewer wirklich stellen. Ich hab sie nach Schwierigkeitsgrad und Art der Rolle sortiert, damit du dich auf das konzentrieren kannst, was für deine Wunschposition am wichtigsten ist. Jede Antwort hat praktische Beispiele und, wenn es passt, Code-Schnipsel, die du anpassen kannst.

Eins solltest du im Kopf behalten: Die Leute, die die Interviews machen, checken viel öfter die Grundlagen als die fortgeschrittenen Themen. Wenn du die Grundlagen (HTTP-Methoden, Statuscodes, Zustandslosigkeit) drauf hast, kannst du die meisten REST-API-Interviews locker meistern. Die coolen architektonischen Muster kommen später.

Grundlegende Fragen zum Thema REST-API im Vorstellungsgespräch

Diese Fragen checken dein Grundwissen. Rechne damit, dass sie in fast jedem Vorstellungsgespräch vorkommen, egal wie hoch die Position ist.

1. Was ist REST und was sind seine Einschränkungen?

REST steht für „Representational State Transfer”. Es ist ein Architekturstil für das Design von vernetzten Anwendungen, den Roy Fielding in seiner Doktorarbeit aus dem Jahr 2000 definiert hat.

REST hat sechs Einschränkungen:

1. Client-Server: Trennung der Aufgaben zwischen Benutzeroberfläche und Datenspeicherung
2. Stateless-: Jede Anfrage hat alle Infos, die man braucht, um sie zu erledigen.
3. Zwischenspeicherbar: Die Antworten müssen angeben, ob sie zwischengespeichert werden können.
4. Schichtbasiertes System-: Komponenten können nicht über ihre unmittelbare Ebene hinaussehen.
5. Einheitliche Schnittstelle: Standardisierte Art, mit Ressourcen zu arbeiten
6. Code-on-Demand (optional): Server können ausführbaren Code an Clients schicken.

2. Was ist der Unterschied zwischen REST und SOAP?

REST ist ein Architekturstil; SOAP ist ein Protokoll. REST nutzt meistens JSON über HTTP und setzt auf Standard-HTTP-Methoden. SOAP nutzt nur XML und hat sein eigenes Nachrichtenformat mit Envelopes und den Adressaten „“.

SOAP ist immer nochsinnvoll für Unternehmenssysteme, die formelle Verträge (WSDL) oder Sicherheit auf Nachrichtenebene (WS-Security) brauchen.

3. Was sind HTTP-Methoden und wann benutzt man welche?

HTTP-Methoden sagen, was mit einer Ressource gemacht werden soll.

4. Was ist der Unterschied zwischen PUT und POST?

POST macht eine neue Ressource, wobei der Server die URI festlegt. PUT ersetzt eine Ressource an einer bestimmten URI, die der Client angibt.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resourceBereitgestellt von

Wenn du einen PUT-Befehl an eine URI sendest, die nicht existiert, kann der Server sie erstellen. Wenn du einen PUT-Befehl an eine vorhandene URI sendest, ersetzt du die ganze Ressource.

5. Was ist der Unterschied zwischen PUT und PATCH?

PUT ersetzt die ganze Ressource. PATCH macht ein paar Änderungen.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "[email protected]", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}Bereitgestellt von

6. Was heißt „zustandslos” in REST?

Stateless heißt, dass jede Anfrage alle Infos haben muss, die der Server braucht, um sie zu bearbeiten. Der Server speichert zwischen den Anfragen keinen Client-Kontext.

Das heißt, keine Server-seitigen Sitzungen. Wenn ein Benutzer authentifiziert ist, muss der Client bei jeder Anfrage Anmeldedaten (normalerweise ein Token) mitschicken.

7. Was macht eine API RESTful?

Eine API ist echt RESTful, wenn sie alle REST-Vorgaben erfüllt, einschließlich HATEOAS (Hypermedia as the Engine of Application State). In der Praxis sind die meisten APIs, die sich selbst als „REST“ bezeichnen, eigentlich „REST-ähnlich“ oder auf Stufe 2 des Richardson-Reifegradmodells. Und ehrlich gesagt ist das für die meisten Fälle völlig okay.

Richardson-Reifegradmodell für REST-APIs. Bild vom Autor.

8. Welche grundlegenden HTTP-Statuscodes solltest du kennen?

Du solltest zumindest diese sieben wichtigen Statuscodes kennen, die die meisten API-Szenarien abdecken:

9. Was ist der Unterschied zwischen einer Ressource und einem Endpunkt?

Eine Ressource ist die Datenentität (Benutzer, Bestellung, Produkt). Ein Endpunkt ist der URL-Pfad, über den man auf diese Ressource zugreifen kann.

Resource: User
Endpoints: GET /users, GET /users/123, POST /usersBereitgestellt von

10. Was sind die besten Vorgehensweisen für das URI-Design?

Benutze Substantive, keine Verben. Schreib URIs klein und benutze Bindestriche für Namen, die aus mehreren Wörtern bestehen. Benutze Pluralformen für Sammlungen.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_itemsBereitgestellt von

Vermeide zu viele Verschachtelungen. Anstelle von /users/123/posts/456/comments/789 solltest du lieber /comments/789 oder /comments?post_id=456 checken .

11. Was ist Idempotenz und welche HTTP-Methoden sind idempotent?

Eine Operation ist idempotent, wenn sie mehrmals durchgeführt wirdund dabeidas gleiche Ergebnis wie bei einmaliger Durchführung erzielt wird.

Ein PATCH, der einen Wert festlegt, istidempotent; ein PATCH, der einen Zähler erhöht, ist es nicht.

12. Was ist der Unterschied zwischen sicheren und idempotenten Methoden?

Sichere Methoden ändern keine Ressourcen (GET, HEAD, OPTIONS). Idempotente Methoden können mehrmals mit dem gleichen Ergebnis aufgerufen werden (GET, PUT, DELETE).

Alle sicheren Methoden sind idempotent, aber nicht alle idempotenten Methoden sind sicher. DELETE ist idempotent, aber nicht sicher, weil es den Status ändert.

13. Wann solltest du Query-Parameter und wann Path-Parameter verwenden?

Pfadparameter zeigen eine bestimmte Ressource an. Abfrageparameter filtern, sortieren oder paginieren Sammlungen.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10Bereitgestellt von

14. Was ist Inhaltsaushandlung?

Mit Content Negotiation können Kunden verschiedene Darstellungen einer Ressource anfordern. Der Client schickt einen „ Accept “-Header und der Server antwortet mit dem passenden Format.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XMLBereitgestellt von

15. Was macht man mit der OPTIONS-Methode?

OPTIONS zeigt die HTTP-Methoden an, die ein Server für eine bestimmte URL unterstützt. Browser nutzen es für CORS-Preflight-Anfragen, um zu checken, ob Cross-Origin-Anfragen erlaubt sind.

Fragen für Vorstellungsgespräche zur REST-API für Fortgeschrittene

Diese Fragen prüfen die praktische Anwendung und Entscheidungsfindung. Rechne damit, dass sie für mittlere Positionen in Frage kommen.

16. Was ist der Unterschied zwischen 401 und 403?

Das sind die beiden Statuscodes, die am häufigsten verwechselt werden. Ich hab schon erlebt, dass erfahrene Entwickler das bei Code-Reviews durcheinandergebracht haben.

401 Nicht autorisiert

Heißt nicht authentifiziert. Der Server weiß nicht, wer du bist. Deine Antwort sollte den Nutzer dazu auffordern, sich anzumelden.

403 Verboten

Heißt: nicht erlaubt. Der Server weiß, wer du bist, aber du hast keine Berechtigung. Eine erneute Authentifizierung bringt nichts.

Entscheidungsdiagramm zum Unterschied zwischen Authentifizierungs- und Autorisierungsfehlern. Bild vom Autor.

17. Was ist der Unterschied zwischen 400 und 422?

Hier sind ein paar Beispiele, die den Unterschied zeigen:

400 Ungültige Anfrage

Das zeigt auf eine fehlerhafte Syntax hin. Der Server kann die Anfrage nicht verarbeiten (falsche JSON-Struktur, fehlende erforderliche Header).

422 Nicht verarbeitbare Entität

Das bedeutet, dass die Syntax okay ist, aber es gibt Probleme mit der Bedeutung. Das JSON ist okay, aber die Daten sind nicht in Ordnung (das E-Mail-Format stimmt nicht, das Passwort ist zu kurz).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validationBereitgestellt von

18. Wann solltest du den 409-Konflikt verwenden?

Verwende 409, wenn die Anfrage mit dem aktuellen Status der Ressource nicht übereinstimmt:

• Optimistische Sperrfehler (ETag-Fehlanpassung)
• Verletzungen der Eindeutigkeitsbeschränkung (doppelte Benutzernamen)
• Ungültige Statusübergänge (Stornierung einer bereits versandten Bestellung)

19. Wie setzt man Paginierung um?

Zwei Hauptansätze:

Offsetbasierte Paginierung

Einfach, aber mit Performance-Problemen bei großen Datensätzen.

GET /users?limit=20&offset=40Bereitgestellt von

Cursorbasierte Paginierung

Skaliert besser und verhindert „Seitenverschiebungen“, wenn sich Daten ändern.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQBereitgestellt von

Firmen wie Stripe, GitHub und Slack nutzen die Cursor-basierte Paginierung für große Datensätze.

20. Was sind gängige Strategien für die API-Versionierung?

Es gibt drei Hauptansätze, die alle ihre Vor- und Nachteile haben:

URI-Versionierung

Das ist das häufigste. Es ist klar und einfach zu debuggen.

GET /v1/users
GET /v2/usersBereitgestellt von

Header-Versionierung

Sauberere URLs, aber schwieriger in Browsern zu testen.

GET /users
Accept-Version: v2Bereitgestellt von

Versionierung von Abfrageparametern

Einfach hinzuzufügen, macht die URLs aber unübersichtlich.

GET /users?version=2Bereitgestellt von

21. Was ist ein ETag und wie funktioniert Caching?

Ein ETag ist eine Versionskennung für eine Ressource. Der Server schickt es in Antworten; der Client schickt es in späteren Anfragen zurück, um zu checken, ob sich die Ressource geändert hat.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)Bereitgestellt von

22. Welche Authentifizierungsmethoden werden für REST-APIs verwendet?

Die vier gängigsten Authentifizierungsmethoden sind API-Schlüssel, Bearer-Token, OAuth 2.0 und JWT:

23. Was ist JWT und wie funktioniert es?

JWT (JSON Web Token) besteht aus drei Teilen: Header, Nutzlast und Signatur. Erfahre mehr über die Arbeit mit JSON in Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)Bereitgestellt von

Der Server unterschreibt das Token; die Clients schicken es mit ihren Anfragen mit. Der Server überprüft die Signatur, ohne in der Datenbank nachzuschauen.

24. Was ist der Unterschied zwischen RS256 und HS256?

HS256 (symmetrisch): Gleiches Geheimnis verschlüsselt und verifiziert. Risiko, wenn mehrere Dienste Tokens überprüfen müssen.

RS256 (asymmetrisch): Der private Schlüssel unterschreibt, der öffentliche Schlüssel überprüft. Empfohlen für verteilte Systeme, in denen mehrere Dienste Token überprüfen.

25. Was ist HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State) heißt, dass Antworten Links zu ähnlichen Aktionen und Ressourcen haben.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}Bereitgestellt von

In der Praxis setzen die meisten APIs HATEOAS nicht komplett um. Kenn das Konzept, aber rechne nicht damit, dass du es in den meisten Jobs umsetzen kannst. Selbst große Tech-Firmen machen selten APIs, die komplett HATEOAS-konform sind.

26. Wie gehst du mit Fehlern konsequent um?

Benutze das Format „RFC 7807 Problem Details” für einheitliche Fehlermeldungen:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}Bereitgestellt von

27. Was ist Ratenbegrenzung und warum ist sie wichtig?

Die Ratenbegrenzung schützt deine API vor Missbrauch und sorgt für eine faire Nutzung. Häufige Antwort:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0Bereitgestellt von

28. Wie machst du das Filtern und Sortieren?

Benutze Abfrageparameter mit klaren Regeln:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,nameBereitgestellt von

Fragen zum Vorstellungsgespräch über die erweiterte REST-API

Diese Fragen checken, wie gut du architektonisch denken kannst. Rechnet damit, dass sie in leitenden Positionen sind.

29. Was hat sich zwischen OAuth 2.0 und OAuth 2.1 geändert?

OAuth 2.1 bringt die besten Sicherheitspraktiken zusammen:

Das Wichtigste: Nutzt den Autorisierungscode-Flow mit PKCE für alle Client-Typen.

30. Wie setzt man Idempotenz für Zahlungsendpunkte um?

Benutze Idempotenzschlüssel, um POST-Anfragen für Wiederholungsversuche sicher zu machen:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return resultBereitgestellt von

Der Client macht eine UUID und schickt sie mit der Anfrage mit. Wenn derselbe Schlüssel wiederkommt, gib einfach die zwischengespeicherte Antwort zurück.

31. Wie würdest du einen verteilten Ratenbegrenzer entwerfen?

Bei verteilten Systemen kannst du keine In-Memory-Zähler verwenden, weil der Datenverkehr über die Instanzen verteilt wird. Das ist ein häufiger Stolperstein, über den viele Bewerber stolpern.

Architektur:

1. Redis für die zentrale Speicherung von Zählern nutzen
2. Implementiere den Token-Bucket-Algorithmus für Burst-Toleranz.
3. Benutz atomare Operationen (Lua-Skripte), um Race Conditions zu vermeiden.

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429Bereitgestellt von

32. Wann würdest du gRPC statt REST nehmen?

Wähle gRPC für:

• Interne Microservice-Kommunikation (5- bis 10-fache Verbesserung des Durchsatzes)
• Anforderungen für Echtzeit-Streaming
• Mobile-to-Backend mit Bandbreitenbeschränkungen
• Mehrsprachige Umgebungen, die strenge Verträge brauchen

Wähle REST für:

• Öffentliche APIs mit vielen verschiedenen Nutzern
• Web-Anwendungen (unterstützt von allen Browsern)
• Einfache CRUD-Operationen
• Teams, die sich mit Protocol Buffers nicht auskennen

33. Wie gehst du mit lang andauernden Vorgängen um?

Benutz das asynchrone Anforderungsmuster:

1. Der Kunde schickt eine Anfrage

2. Der Server schickt eine Fehlermeldung zurück ( 202 Accepted ) mit einer Status-URL.

3. Der Client fragt die Status-URL ab, bis der Vorgang abgeschlossen ist.

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}Bereitgestellt von

34. Was ist das Saga-Muster?

Saga macht verteilte Transaktionen über Microservices hinweg, ohne dass es zu Sperren kommt. Jeder Dienst macht eine lokale Transaktion und veröffentlicht ein Ereignis. Wenn ein Schritt nicht klappt, machen Ausgleichstransaktionen die vorherigen Schritte rückgängig.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel OrderBereitgestellt von

35. Was sind häufige Sicherheitslücken bei JWT?

Algorithmus-Verwirrung Der Angreifer tauscht RS256 gegen HS256 aus und unterschreibt mit dem öffentlichen Schlüssel. Lösung: Algorithmen immer auf die Whitelist setzen.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])Bereitgestellt von

„Keiner“-Algorithmus: Der Angreifer löscht die Signatur komplett. Fix: „none“-Algorithmus ablehnen.

Backend-Entwickler REST-API-Fragen

36. Was ist das N+1-Abfrageproblem?

Das N+1-Problem tritt auf, wenn du N Datensätze abrufst und dann für jede Beziehung eines Datensatzes eine separate Abfrage durchführst.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queriesBereitgestellt von

Lösungen:

Django: Benutze „ select_related() ” für Fremdschlüssel und „prefetch_related() ” für viele-zu-viele-Beziehungen.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()Bereitgestellt von

SQLAlchemy: Schau mal auf joinedload() oder selectinload() vorbei.

37. Wie stellst du das Connection Pooling ein?

Beim Connection Pooling werden Datenbankverbindungen wiederverwendet, statt für jede Anfrage neue zu erstellen.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)Bereitgestellt von

38. Welche Caching-Strategien kennst du?

Es gibt drei Hauptstrategien für das Caching, die jeweils für unterschiedliche Zugriffsmuster optimiert sind:

39. Wie setzt man die Webhook-Signaturüberprüfung um?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)Bereitgestellt von

40. Welche Kennzahlen zeigen, ob die API gut läuft?

Du solltest diese vier wichtigen Kennzahlen im Auge behalten, um zu sehen, wie gut deine API läuft:

Full-Stack-Entwickler REST-API-Fragen

41. Wann schickt ein Browser eine CORS-Preflight-Anfrage?

Browser schicken einen OPTIONS-Preflight für:

• Andere Methoden als GET, HEAD, POST
• Benutzerdefinierte Header (Autorisierung, X-API-Key)
• Anderer Content-Type als form-urlencoded, multipart/form-data, text/plain

42. Wie stellst du CORS sicher ein?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));Bereitgestellt von

Benutze niemals Platzhalter (*) mit Anmeldedaten. Erlaube niemals die Herkunft „ null “.

43. Wo solltest du Tokens auf dem Client speichern?

Bei der Token-Speicherung muss man zwischen XSS- und CSRF-Sicherheitslücken abwägen.

Bewährte Vorgehensweise: SpeichereAktualisierungstoken in HttpOnly-Cookies mit „ SameSite=Strict “. Speichere Zugriffstoken im Speicher.

44. Wann solltest du WebSockets und wann SSE nutzen?

Die Entscheidung hängt davon ab, ob du bidirektionale Kommunikation brauchst und wie du die Wiederverbindung handhaben willst:

Verwende SSE für Benachrichtigungen, Live-Feeds und Börsenticker. Nutze WebSockets für Chats, Multiplayer-Spiele und gemeinsames Bearbeiten.

45. Wie gehst du mit Datei-Uploads um?

Für große Dateien solltest du Chunked Uploads mit Fortschrittsanzeige nutzen:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}Bereitgestellt von

Szenariobasierte Fragen zur REST-API

46. Entwickle eine REST-API für ein Hotelbuchungssystem.

Ressourcen:

• /hotels - Hotels auflisten und suchen

• /hotels/{id}/rooms - Verfügbare Zimmer

• /bookings - Buchungen erstellen und verwalten

• /guests/{id} - Gastprofile

Wichtige Entscheidungen:

• Benutze die Cursor-basierte Paginierung für die Hotelsuche.
• Optimistische Sperren für die Verfügbarkeit von Räumen einrichten
• 409 Konflikt bei doppelten Buchungsversuchen zurückgeben
• Verwende idempotente Schlüssel für die Zahlungsabwicklung

47. Wie würdest du Soft Deletes umsetzen?

Füge einen deleted_at Zeitstempel hinzufügen, anstatt Datensätze zu löschen:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()Bereitgestellt von

48. Wie kann man von Version 1 auf Version 2 umsteigen, ohne dass die Clients kaputtgehen?

Benutz das Strangler-Fig-Muster:

1. V2 neben V1 bereitstellen
2. Neue Funktionen zu v2 weiterleiten
3. Migriere nach und nach die vorhandenen Endpunkte
4. Kommuniziere die Abkündigung über den Sunset-Header
5. Entferne v1 nach der Migrationsphase

49. Wie würdest du eine Such-API mit komplexen Filtern gestalten?

Für eine Produktsuche mit mehreren Filtern:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123Bereitgestellt von

Entscheidungen zum Design:

• Benutz Elasticsearch für die Volltextsuche (relationale Datenbanken haben Probleme mit unscharfen Übereinstimmungen).
• Implementiere eine facettierte Suche, um die verfügbaren Filteroptionen anzuzeigen.
• Zeigt die Anzahl der Filterergebnisse an, damit die Nutzer wissen, wie viele Ergebnisse jeder Filter liefert.
• Beliebte Suchkombinationen zwischenspeichern

50. Wie gehst du mit der API-Versionierung in einer Microservices-Architektur um?

Optionen:

1. Versionsverwaltung auf Gateway-Ebene: API-Gateway leitet /v1/* zu alten Diensten und /v2/* zu neuen Diensten weiter.

2. Versionsverwaltung auf Serviceebene: Jeder Dienst kümmert sich um seine eigene Versionsaushandlung.

3. Verträge, die auf die Bedürfnisse der Verbraucher zugeschnitten sind: Benutz Pact oder ähnliche Tools, um die Kompatibilität sicherzustellen.

Für die meisten Teams ist die Versionierung auf Gateway-Ebene die sauberste Trennung.

51. Wie würdest du die Ratenbegrenzung für verschiedene Benutzerstufen umsetzen?

Die Lösung besteht darin, für jede Ebene eigene Limits festzulegen und diese mit Redis-Zählern zu checken:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )Bereitgestellt von

Fragen zur Verhaltens-REST-API

52. Erkläre REST jemandem, der nicht technisch versiert ist.

Stell dir eine REST-API wie einen Kellner in einem Restaurant vor. Du (der Kunde) darfst nicht direkt in die Küche gehen. Stattdessen sagst du dem Kellner, was du von der Speisekarte haben möchtest, und er bringt es dir. Das Menü ist wie die API-Dokumentation und zeigt, was du bestellen kannst. Der Kellner hält sich an bestimmte Regeln: Du fragst nach etwas (GET), bestellst was Neues (POST) oder schickst was zurück (DELETE). Wenn in der Küche was nicht da ist, sagt dir der Kellner Bescheid (404 Not Found), damit du nicht ewig warten musst.

Diese Analogie funktioniert echt gut bei Stakeholder-Meetings.

53. Erzähl mal von einer Situation, in der du eine API optimiert hast.

Probier mal die STAR-Methode aus:

• Situation: Unsere Such-API hat bei viel Traffic nur 3 Sekunden gebraucht, um zu antworten.
• Aufgabe: Ich musste die Latenzzeit ohne große Änderungen an der Architektur runterbringen.
• Maßnahme: Ich hab Redis-Caching für oft vorkommende Abfragen eingebaut, eine Cursor-basierte Paginierung gemacht und Datenbankindizes hinzugefügt.
• Ergebnis: Die Reaktionszeit ist auf 200 ms gesunken, und wir haben fünfmal mehr Datenverkehr geschafft.

54. Wie sagst du den Leuten, die die API nutzen, von wichtigen Änderungen Bescheid?

1. Frühzeitig ankündigen: Große Änderungen solltest du mindestens 6 bis 12 Monate vorher ankündigen.

2. Verwende den Sunset-Header: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Stell Migrationsanleitungen bereit: Dokumentiere genau, was sich ändert und wie man sich anpassen kann.

4. Führ einfach beide Versionen aus: Lass die alte Version während der Umstellung weiterlaufen.

5. Überwachungsnutzung: Verfolge, welche Kunden noch die alte Version nutzen.

55. Welche Dokumentation erstellst du für APIs?

Zu den wichtigen Unterlagen gehören:

• OpenAPI/Swagger-Spezifikation: Maschinenlesbarer Vertrag
• Anleitung für den Einstieg: Erster API-Aufruf in weniger als 5 Minuten
• Anleitung zur Authentifizierung: Wie man Zugangsdaten bekommt und benutzt
• Fehlerreferenz: Alle möglichen Fehlercodes und wie man damit umgeht
• Änderungsprotokoll: Was hat sich in jeder Version geändert?
• Dokumentation zur Ratenbegrenzung: Limits pro Stufe und wie man mit 429s umgeht

56. Wann würdest du REST NICHT verwenden?

REST ist nicht immer die beste Wahl. Zu wissen, wann man Alternativen zu „ “ einsetzt, zeigt, dass man architektonisch auf dem neuesten Stand ist. Ich hab schon Teams gesehen, die REST in Anwendungsfälle reingezwängt haben, wo es mehr Probleme verursacht als löst.

REST-API-Schnellreferenz

Nutze diesen Abschnitt als Schnellübersicht, wenn du während der Vorbereitung auf Vorstellungsgespräche oder in der praktischen Entwicklung die Eigenschaften von HTTP-Methoden, Statuscodes oder gängige Muster überprüfen musst.

Vergleich der HTTP-Methoden

Diese Tabelle zeigt die wichtigsten Eigenschaften der einzelnen HTTP-Methoden und hilftdir dabei, die richtige für deinen Anwendungsfall zu finden.

Referenz zu Status-Codes

Hier sind die am häufigsten verwendeten HTTP-Statuscodes, sortiert nach Kategorien. Konzentrier dich darauf, zu verstehen, wann du was benutzt, statt dir die ganze Spezifikation zu merken.

2xx Erfolgreich

• 200 OK: Erfolgreiches GET, PUT, PATCH
• 201 Erstellt: Erfolgreicher POST (inklusive Location-Header)
• 204 Kein Inhalt: Erfolgreich gelöscht

4xx Client-Fehler

• 400 Schlechte Anfrage: Fehlerhafte Syntax
• 401 Nicht autorisiert: Authentifizierung nötig
• 403 Verboten: Authentifiziert, aber nicht autorisiert
• 404 Nicht gefunden: Die Ressource ist nicht da.
• 409 Konflikt: Staatlicher Konflikt
• 422 Nicht verarbeitbare Entität: Validierungsfehler
• 429 Zu viele Anfragen: Ratenbegrenzt

5xx Serverfehler

• 500 Interner Serverfehler: Allgemeiner Serverausfall
• 502 Fehlerhafter Gateway: Fehler beim Upstream-Server
• 503 Dienst nicht verfügbar: Im Moment überlastet

Häufige Fehler, die du vermeiden solltest

Selbst erfahrene Entwickler tappen in diese Fallen. Pass auf diese häufigen Fallstricke bei der Entwicklung oder Implementierung von REST-APIs auf:

• Verben in URLs verwenden (z. B. /getUsers statt /users)

• Rückgabe von 200 OK bei Fehlerzuständen, was die Fehlerbehandlung auf der Clientseite kaputt macht

• Verwirrung zwischen 401 und 403 „ ” (Authentifizierung vs. Genehmigung)

• URLs mit mehr als zwei Ebenen über zwei Ebenen hinaus

• Speichern von Tokens in localStorage (führt zu XSS-Schwachstellen)

• Idempotenz ignorieren bei POST-Anfragen

• Allgemeine Fehlermeldungen ohne nützliche Details

Fazit

Ich weiß, dass das Auswendiglernen von Definitionen nicht garantiert, dass du jedes technische Vorstellungsgespräch schaffst. Die Wahrheit ist, dass man in der echten Welt oft die „strengen“ Regeln, über die wir gerade gesprochen haben, brechen muss, und die Leute, die dich interviewen, interessieren sich mehr für deine Argumentation als dafür, ob du die RFC-Spezifikationen auswendig kannst. Bei hochspezialisierten Jobs können fundierte Fachkenntnisse oder spezifisches Framework-Know-how immer noch der entscheidende Faktor sein.

Aber diese REST-Grundlagen zu verstehen ist wichtig, auch wenn du nicht genau diese Fragen bekommst. Es ist wie eine Anleitung, um zu verstehen, wie das moderne Internet funktioniert. Wenn du ein neues System entwickeln oder einen Produktionsausfall beheben sollst, hilft dir das Verständnis des Unterschieds zwischen einem 401- und einem 403-Fehler (wie ich vorhin erklärt habe) dabei, Probleme schneller zu lösen. Du wirst genau erkennen, warum die Standardisierung deiner API-Interaktionen und nicht nur das Schreiben von funktionierendem Code das Markenzeichen eines erfahrenen Entwicklers ist.

Wenn du dich näher mit der Entwicklung dieser Systeme beschäftigen möchtest, schau dir unsere Kurs „Einführung in APIs in Python“ an.