Interviewfragen zum API-Design (Middle) mit Antworten

75 Fragen fürs Vorstellungsgespräch zum API-Design (Middle) mit richtigen Antworten, Erklärungen und Links zur Dokumentation.

Diesen Test machen
  1. 1.Wie würdest du „Bestellung stornieren“ in einer REST-API modellieren?
  2. 2.Wann sollte eine Beziehung eine eigene Ressource sein, etwa /users/42/memberships?
  3. 3.Wie sollte eine Anfrage mit JSON Merge Patch null behandeln?
  4. 4.Wie sieht JSON Patch (RFC 6902) aus?
  5. 5.Wie kann eine REST-API Clients verwandte Ressourcen in einer Anfrage laden lassen?
  6. 6.Was bringen Sparse Fieldsets (?fields=id,name,email) Clients?
  7. 7.Warum nutzt eine API eventuell UUIDs oder opake String-IDs statt hochzählender Ganzzahlen in URLs?
  8. 8.Wie sollte eine API Geldbeträge darstellen?
  9. 9.Wie sollten Validierungsfehler für mehrere Felder gemeldet werden?
  10. 10.Warum sollten Fehlercodes im Body stabil und dokumentiert sein?
  11. 11.Welcher Status passt zu einer wohlgeformten Anfrage, die eine Geschäftsregel verletzt, etwa „unbezahlte Bestellung kann nicht versendet werden“?
  12. 12.Sollte eine API 403 oder 404 liefern, wenn ein Nutzer die private Ressource eines anderen anfragt?
  13. 13.Warum erzeugt Offset-Paginierung Duplikate oder Lücken, wenn beim Blättern Einträge eingefügt werden?
  14. 14.Warum ist eine Gesamtzahl bei jeder Seite manchmal ein Problem?
  15. 15.Was ist bei der Sortierung einer Cursor-paginierten Liste wichtig?
  16. 16.Wie kann eine API flexibles Filtern bieten, ohne zu einer Abfragesprache zu werden, die niemand optimieren kann?
  17. 17.Wie sollten Sortierparameter meist aussehen?
  18. 18.Wie funktioniert ein Idempotenzschlüssel auf dem Server?
  19. 19.Zwei Clients bearbeiten dasselbe Dokument. Wie verhindert eine API, dass einer den anderen still überschreibt?
  20. 20.Was spart 304 Not Modified?
  21. 21.Warum sind Wiederholungen für nicht idempotente Operationen ohne Schutz gefährlich?
  22. 22.Was bedeutet Cache-Control: private, max-age=60?
  23. 23.Was ist der Unterschied zwischen no-cache und no-store?
  24. 24.Was erlaubt stale-while-revalidate?
  25. 25.Warum ist der Header Vary beim Cachen von API-Antworten wichtig?
  26. 26.Was zählt in einer REST-API als brechende Änderung?
  27. 27.Was ist Hyrums Gesetz?
  28. 28.Was sind die Kompromisse von URL-Versionierung (/v2/...) gegenüber Header-Versionierung?
  29. 29.Wie entwickelt man das Format eines Felds ohne neue Hauptversion weiter?
  30. 30.Was ist in einer API der Unterschied zwischen Authentifizierung und Autorisierung?
  31. 31.Was beschreibt OWASP API1:2023 Broken Object Level Authorization?
  32. 32.Was ist Broken Object Property Level Authorization (OWASP API3:2023)?
  33. 33.Warum sollten Access Tokens kurzlebig sein?
  34. 34.Wofür nutzt man OAuth-Scopes?
  35. 35.Wie sollten Aufrufe zwischen Diensten innerhalb eines Systems authentifiziert werden?
  36. 36.Warum sollten Rate Limits pro Client (API-Schlüssel oder Nutzer) statt nur pro IP gelten?
  37. 37.Was umfasst OWASP API4:2023 Unrestricted Resource Consumption?
  38. 38.Wie verhält sich ein Client gut, wenn er 429 oder 503 bekommt?
  39. 39.Wie sollte ein Webhook-Empfänger prüfen, dass eine Anfrage wirklich vom Anbieter kommt?
  40. 40.Warum sollten Webhook-Handler idempotent sein?
  41. 41.Warum sollte ein Webhook-Endpunkt schnell antworten und das Event asynchron verarbeiten?
  42. 42.Kann man annehmen, dass Webhook-Events der Reihe nach ankommen?
  43. 43.Warum ist HTTP-Caching mit GraphQL schwieriger als mit REST?
  44. 44.Wie unterscheiden sich GraphQL-Fehler von REST-Fehlern?
  45. 45.Wie geht GraphQL meist mit der Weiterentwicklung des Schemas um?
  46. 46.Wann ist tRPC eine gute Wahl?
  47. 47.Was beschreibt AsyncAPI?
  48. 48.Wie sollte eine API eine Massenoperation behandeln, bei der einige Einträge scheitern?
  49. 49.Warum ist ein großer Export eventuell besser ein asynchroner Job als ein einzelnes GET?
  50. 50.Wie können Clients große Dateien hochladen, ohne sie durch den API-Server zu schicken?
  51. 51.Was macht API-Dokumentation wirklich nützlich?
  52. 52.Wie findet man brechende Änderungen in einer OpenAPI-Spezifikation automatisch?
  53. 53.Was sind Vertragstests zwischen einem Client und einer API?
  54. 54.Warum SDKs oder Clients aus einer OpenAPI-Spezifikation erzeugen?
  55. 55.Wie sollte eine API mit Zeitzonen in Ein- und Ausgaben umgehen?
  56. 56.Was ist ein sinnvoller Standard für unbekannte Query-Parameter?
  57. 57.Warum sollten Listenantworten eine stabile Standardsortierung haben?
  58. 58.Was ändert ein „Backend for Frontend“ am API-Design?
  59. 59.Was übernimmt ein API-Gateway typischerweise?
  60. 60.Wie sollte eine API Aktionen auf vielen Einträgen bereitstellen, etwa „500 Nachrichten archivieren“?
  61. 61.Warum eine Korrelations-ID in Fehlerantworten aufnehmen?
  62. 62.Was ist das Risiko, interne Fehlermeldungen (etwa SQL-Fehler) an API-Clients weiterzugeben?
  63. 63.Wann kann PUT mit vollständigem Dokument besser sein als PATCH?
  64. 64.Warum sollten API-Antworten nulls für „nicht zutreffend“ und „unbekannt“ nicht ohne Dokumentation ausgeben?
  65. 65.Was ist Versionierung per Media Type?
  66. 66.Worum bittet der Request-Header Prefer: return=minimal?
  67. 67.Warum kann eine API auf Browser-Anfragen mit Credentials nicht mit Access-Control-Allow-Origin: * antworten?
  68. 68.Eine Browser-SPA authentifiziert sich per Cookies bei ihrer API. Welchen zusätzlichen Schutz braucht es im Vergleich zu Bearer-Tokens?
  69. 69.Wie sollte ein API-Anbieter die von ihm ausgegebenen API-Schlüssel speichern?
  70. 70.Wann ist POST /orders/search mit JSON-Body statt GET mit Query-Parametern akzeptabel?
  71. 71.Wofür ist die Konvention /users/me (oder /me) da?
  72. 72.Wann sollte eine API 410 Gone statt 404 liefern?
  73. 73.Welcher Status passt zu einem Request-Body, der größer ist als die API erlaubt?
  74. 74.Warum ist eine stabile operationId in OpenAPI wichtig?
  75. 75.Wie sollten Webhook-Payloads versioniert werden?