REST-API-Interviewfragen und Antworten (2026): Methoden, Statuscodes und Design

REST-API-Fragen testen, ob du eine Schnittstelle entwerfen kannst, die andere ohne Überraschungen nutzen. Unten findest du 20 Fragen mit Antworten, von den Grundlagen bis zu den Designdetails, die in Backend- und Full-Stack-Interviews auftauchen. Für die Regeln zu HTTP-Methoden haben wir uns an die Definitionen in RFC 9110 gehalten.

Grundlagen

1. Was ist REST?

REST ist ein Architekturstil für vernetzte Systeme, der auf Ressourcen basiert, die durch URLs identifiziert, mit einer kleinen Menge standardisierter Operationen bearbeitet und durch Repräsentationen wie JSON beschrieben werden. Eine REST-API ist zustandslos: Jede Anfrage enthält alles, was der Server zu ihrer Bearbeitung braucht, sodass jeder Server jede Anfrage beantworten kann.

2. Was macht eine API in der Praxis „RESTful"?

• Substantive für Ressourcen in URLs, etwa /orders/42, nicht Verben wie /getOrder
• Standard-HTTP-Methoden für Aktionen
• Aussagekräftige Statuscodes
• Zustandslose Anfragen
• Einheitliche Repräsentationen und Fehlerformate

Sag im Interview, dass nur wenige echte APIs jede REST-Einschränkung einhalten und dass es dir auf vorhersehbares Verhalten ankommt.

3. Wofür werden die wichtigsten HTTP-Methoden verwendet?

„Sicher" bedeutet, dass die Anfrage den Serverzustand nicht verändert. „Idempotent" bedeutet, dass mehrfaches Senden dieselbe Wirkung hat wie einmaliges Senden.

4. Was bedeutet idempotent, und warum ist das wichtig?

Wird eine Anfrage wiederholt, ist der Endzustand derselbe wie nach einer Anfrage. Das ist wichtig, weil Netzwerke ausfallen. Läuft bei einem Client ein PUT in einen Timeout, kann er es bedenkenlos erneut senden. Ein POST, der eine Bestellung anlegt, könnte zwei anlegen, deshalb akzeptieren APIs oft einen Idempotenzschlüssel: Der Client sendet einen eindeutigen Schlüssel, und der Server gibt das gespeicherte Ergebnis zurück, wenn er den Schlüssel erneut sieht.

5. PUT oder PATCH?

PUT ersetzt die gesamte Ressource durch den Body, den du sendest, und Felder, die du weglässt, werden gelöscht oder zurückgesetzt. PATCH ändert nur die Felder, die du sendest. Nutze PATCH für kleine Aktualisierungen und PUT, wenn der Client die vollständige Repräsentation hat.

Statuscodes und Fehler

6. Welche Statuscodes verwendest du, und wann?

Eine häufige Nachfrage ist der Unterschied zwischen 401 und 403. 401 bedeutet „Ich weiß nicht, wer du bist", und 403 bedeutet „Ich weiß, wer du bist, und du darfst das nicht".

7. Wie sollte eine API Fehler zurückgeben?

Verwende den richtigen Statuscode und einen einheitlichen Body. Ein guter Fehler-Body hat einen stabilen, maschinenlesbaren Code, eine für Menschen lesbare Nachricht und bei Validierungsfehlern die Angabe, welche Felder fehlgeschlagen sind. Gib keine Stacktraces oder internen Details an Clients weiter.

8. Wie gehst du mit Validierung um?

Validiere auf dem Server, auch wenn der Client ebenfalls validiert. Gib nach Möglichkeit alle Probleme auf einmal zurück, damit der Nutzer sie nicht einzeln nacheinander beheben muss, und verwende 400 oder 422 einheitlich.

Design

9. Wie entwirfst du URLs für Beziehungen?

Verschachtele, wenn das Kind nur unter dem Elternteil Sinn ergibt, wie /users/7/orders. Halte die Verschachtelung flach. Ab einer oder zwei Ebenen gib das Kind direkt an, wie /orders/42, und filtere mit Query-Parametern, wie /orders?userId=7.

10. Wie paginierst du eine Liste?

Cursor-Paginierung ist die übliche Antwort für große oder sich schnell ändernde Daten. Gib den nächsten Cursor zurück und einen Hinweis, ob weitere Ergebnisse existieren.

11. Wie filterst und sortierst du?

Verwende Query-Parameter, wie ?status=open&sort=-created_at. Führe eine Whitelist der erlaubten Felder, um nicht indizierte oder sensible Spalten nicht preiszugeben und Abfragen schnell zu halten.

12. Wie versionierst du eine API?

Was auch immer du wählst, vermeide Breaking Changes innerhalb einer Version. Felder hinzuzufügen ist meist sicher, Felder zu entfernen oder umzubenennen nicht.

13. Was ist HATEOAS?

Antworten enthalten Links zu verwandten Aktionen, sodass ein Client entdecken kann, was er als Nächstes tun kann, anstatt URLs fest zu codieren. Es ist Teil der REST-Definition, aber nur wenige APIs implementieren es vollständig. Sag, dass du es kennst und dass die meisten Teams stattdessen Dokumentation und eine OpenAPI-Beschreibung verwenden.

Sicherheit und Performance

14. Wie authentifizierst du eine API?

Übliche Optionen sind API-Schlüssel für einfache Server-zu-Server-Nutzung, Bearer-Tokens wie JSON Web Tokens und OAuth 2.0, wenn ein Nutzer einer App Zugriff auf seine Daten gewährt. Verwende immer HTTPS. Halte Geheimnisse aus URLs heraus, da URLs in Logs landen.

15. Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Authentifizierung bedeutet, zu beweisen, wer du bist. Autorisierung bedeutet, zu entscheiden, was du tun darfst. Sie schlagen unterschiedlich fehl: ein fehlendes oder ungültiges Token ist 401, und ein gültiges Token ohne Berechtigung ist 403.

16. Wie schützt du eine API vor Missbrauch?

Rate Limiting pro Schlüssel oder pro IP, Größenbeschränkungen für Anfragen, Eingabevalidierung, Timeouts und Überwachung auf ungewöhnlichen Verkehr. Gib 429 mit einem Retry-After-Header zurück, damit Clients wissen, wann sie es erneut versuchen sollen.

17. Wie funktioniert HTTP-Caching für APIs?

Antworten können Cache-Control-Header tragen, die angeben, wie lange eine Antwort wiederverwendet werden darf. Ein ETag identifiziert eine Version der Antwort. Der Client sendet es in If-None-Match zurück, und der Server antwortet mit 304 Not Modified ohne Body, wenn sich nichts geändert hat. Das spart Bandbreite und Last.

18. Was ist CORS?

Browser blockieren, dass eine Webseite Antworten von einem anderen Origin liest, es sei denn, der Server erlaubt es. Der Server sendet Header wie Access-Control-Allow-Origin, um anzugeben, welche Origins seine Antworten lesen dürfen. Es wird vom Browser durchgesetzt, nicht vom Server, daher schützt es eine API nicht vor Nicht-Browser-Clients.

Praxis

19. REST oder GraphQL oder gRPC?

Die beste Antwort nennt eine Situation, nicht einen Gewinner.

20. Wie dokumentierst und testest du eine API?

Beschreibe sie mit einer OpenAPI-Spezifikation, die Dokumentation und Client-Code generieren kann. Teste auf drei Ebenen: Unit-Tests für die Logik, Integrationstests gegen eine echte Datenbank und Contract-Tests, um Breaking Changes zu erkennen. Probiere auch die Fehlerfälle aus, wie ungültige Eingaben und abgelaufene Tokens.

Wie du dich vorbereitest

1. Sei in der Lage, eine kleine API auf einem Whiteboard zu entwerfen, wie eine To-do-Liste oder ein Bestellsystem, mit URLs, Methoden, Statuscodes und einer Fehlerantwort.
2. Beherrsche Idempotenz und Paginierung aus dem Effeff. Sie kommen am häufigsten vor.
3. Bereite eine Geschichte über eine API vor, die du gebaut oder genutzt hast, und einen Fehler, den du nächstes Mal vermeiden würdest.

Für verwandte Übung siehe unsere Leitfäden zu Spring Boot interview questions, Node.js interview questions, system design interview questions und computer networking interview questions.

Übe laut und in deinen eigenen Worten. Ein Transkript danach zeigt, wo du abgeschweift bist oder den Punkt verpasst hast. Befolge die Regeln des Arbeitgebers zu KI-Tools in jedem Live-Interview oder Assessment.