Interviewfragen zum API-Design (Senior) mit Antworten

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

Diesen Test machen
  1. 1.Wie wählt man für ein neues System zwischen REST, GraphQL und gRPC?
  2. 2.Was ist eine Denkweise „API als Produkt“?
  3. 3.Warum API-Governance (Styleguide, Reviews, Linting) in einer Organisation mit vielen Teams einführen?
  4. 4.Wie wirken Hyrums Gesetz und „sei konservativ in dem, was du sendest“ bei der Weiterentwicklung einer API zusammen?
  5. 5.Wie funktioniert datumsbasierte API-Versionierung (wie bei Stripe)?
  6. 6.Was sind die Hauptkosten, viele API-Versionen gleichzeitig zu unterstützen?
  7. 7.Wie entfernt man ein viel genutztes Feld sicher?
  8. 8.Warum ist eine Änderung des Standardverhaltens (etwa einer Standard-Seitengröße) eine brechende Änderung?
  9. 9.Eine API schreibt in eine primäre Datenbank und liest aus Replicas. Ein Client legt einen Eintrag an und listet sofort die Einträge, ohne ihn zu sehen. Wie sollte das API-Design damit umgehen?
  10. 10.Wie sollte eine mehrstufige Operation über mehrere Dienste in einer API bereitgestellt werden?
  11. 11.Wie sollten sich Idempotenzschlüssel verhalten, wenn die erste Anfrage noch läuft und eine Wiederholung eintrifft?
  12. 12.Wie lange sollte ein Server Idempotenzschlüssel aufbewahren?
  13. 13.Welches Problem löst ein Webhook-Design mit „dünnen Events“?
  14. 14.Wie sollte ein Webhook-System mit einem Abonnenten umgehen, der seit Tagen scheitert?
  15. 15.Was sind die Risiken, Webhooks an beliebige vom Kunden angegebene URLs zu senden?
  16. 16.Wie entwirft man einen API-Endpunkt, dessen zugrunde liegende Abfrage teuer und beliebt ist?
  17. 17.Was bedeutet ein p99-Latenz-SLO einer API für ihre Abhängigkeiten?
  18. 18.Wie sollte sich eine öffentliche API vor missbräuchlichen oder teuren Nutzungsmustern schützen?
  19. 19.Was ist kostenbasiertes Rate Limiting?
  20. 20.Warum ändert HTTP/2 die Abwägungen beim Bündeln vieler kleiner API-Anfragen?
  21. 21.Warum sind persistierte (per Allowlist erlaubte) Abfragen für öffentliche GraphQL-APIs wertvoll?
  22. 22.Wie sollte ein GraphQL-Schema Mutations für eine gute Client-Erfahrung modellieren?
  23. 23.Was ist das Risiko, Datenbankmodelle direkt als GraphQL-Schema offenzulegen?
  24. 24.Warum schaltet man Introspection für eine öffentliche GraphQL-API in Produktion eventuell ab?
  25. 25.Was sind die Regeln der Rückwärtskompatibilität für Protocol-Buffers-Nachrichten?
  26. 26.Welche gRPC-Funktionen gehen über eine typische REST-API hinaus?
  27. 27.Wie stellt man einen gRPC-Dienst Browsern und REST-Clients bereit, ohne Logik zu duplizieren?
  28. 28.Was ist der Unterschied zwischen OWASP API1 (BOLA) und API5 (Broken Function Level Authorization)?
  29. 29.Wovor warnt OWASP API6:2023 (Unrestricted Access to Sensitive Business Flows)?
  30. 30.Worauf bezieht sich OWASP API9:2023 (Improper Inventory Management)?
  31. 31.Was umfasst OWASP API10:2023 (Unsafe Consumption of APIs)?
  32. 32.Warum sollten JWT-Access-Tokens für APIs streng validiert werden?
  33. 33.Was ergänzt Mutual TLS (mTLS) bei APIs zwischen Diensten?
  34. 34.Wie kann eine API die Auswirkung geleakter Zugangsdaten minimieren?
  35. 35.Welche Metriken beschreiben die Gesundheit einer API aus Sicht der Verbraucher am besten?
  36. 36.Wie sollten SLOs für eine öffentliche API definiert werden?
  37. 37.Warum W3C-traceparent-Header durch APIs weiterreichen?
  38. 38.Wie führt man eine riskante API-Änderung sicher ein?
  39. 39.Was ist das Muster „Long-Running Operation“ in den API-Leitlinien von Google?
  40. 40.Welches Problem lösen „Field Masks“ bei Update-Operationen?
  41. 41.Warum nutzt eine API eventuell ressourcenorientierte „eigene Methoden“ wie POST /orders/42:cancel?
  42. 42.Wie entwirft man Paginierung für einen Feed, der konsistent bleiben muss, während neue Einträge ankommen?
  43. 43.Wie stellt man teure berechnete Aggregate bereit, etwa Monatsumsatz pro Kunde?
  44. 44.Wie kann eine API Offline-First-Mobile-Clients unterstützen?
  45. 45.Was ist der Kompromiss einer generischen Abfrage-API (etwa OData-Filter oder roher GraphQL-Zugriff auf alle Daten)?
  46. 46.Warum können „geschwätzige“ interne APIs in Microservices zum Problem werden?
  47. 47.Was ist ein Nachteil von zu viel Logik in einem API-Gateway?
  48. 48.Wie sollte eine API mit personenbezogenen Daten umgehen, um Datenschutzanforderungen wie die DSGVO zu unterstützen?
  49. 49.Warum sollte eine API selbst mit Autorisierung keine fortlaufenden, erratbaren IDs für sensible Ressourcen nutzen?
  50. 50.Wie sollten mandantenfähige APIs Datenlecks zwischen Mandanten verhindern?
  51. 51.Wie wählt man zwischen Webhooks, SSE, WebSockets und Polling zur Zustellung von Updates?
  52. 52.Wie sollte sich eine Echtzeit-API von Verbindungsabbrüchen erholen, ohne Events zu verlieren?
  53. 53.Warum Echtzeit- und Event-APIs mit AsyncAPI dokumentieren?
  54. 54.Was ist verbrauchergetriebenes Contract Testing?
  55. 55.Wie erkennt man vor einer Verhaltensänderung der API, welche Clients brechen würden?
  56. 56.Warum können Wiederholungen auf mehreren Ebenen (Client, Gateway, Dienst) „Retry Storms“ auslösen?
  57. 57.Was ist Request Hedging, und wann ist es angebracht?
  58. 58.Wie sollte eine API mitteilen, dass eine Anfrage teilweise angewandt wurde und nicht sicher wiederholt werden kann?
  59. 59.Was bedeutet es, eine API „von außen nach innen“ zu entwerfen?
  60. 60.Warum bietet man eventuell offizielle SDKs zusätzlich zur rohen HTTP-Dokumentation an?
  61. 61.Was ist das Risiko enger Kopplung zwischen der Antwortform einer API und einem einzelnen UI-Bildschirm?
  62. 62.Wie sollte man brechende Änderungen an Fehlerformaten behandeln?
  63. 63.Wann braucht eine API standardmäßig explizite optimistische Nebenläufigkeit (ETags/If-Match)?
  64. 64.Warum sollten Timeouts Teil des dokumentierten Vertrags einer API sein?
  65. 65.Wie ersetzt man eine Legacy-API durch eine neue Implementierung ohne Big-Bang-Umstellung?
  66. 66.Was sind geplante „Brownouts“ beim Stilllegen einer API-Version?
  67. 67.Wie verhindert man, dass ein großer Mandant eine geteilte API für alle verschlechtert?
  68. 68.Wann bietet eine API eventuell Protobuf oder ein anderes Binärformat zusätzlich zu JSON an?
  69. 69.Was ist das Risiko, authentifizierte API-Antworten an einem CDN zu cachen?
  70. 70.Warum versprechen eventgetriebene APIs meist „mindestens einmal“ statt „genau einmal“?
  71. 71.Wofür nutzt man eine Schema Registry in eventgetriebenen APIs (etwa mit Kafka)?
  72. 72.Was ergänzt das Signieren von Anfragen (etwa HMAC-basiert wie AWS SigV4) über ein Bearer-Token hinaus?
  73. 73.Wie sollte ein API-Design mit Anforderungen an die Datenresidenz umgehen (etwa: EU-Daten bleiben in der EU)?
  74. 74.Warum sollten Paginierungs-Tokens an die Abfrage gebunden sein, die sie erzeugt hat?
  75. 75.Wo sollten Kontingente und Rate Limits pro Tarif dokumentiert sein?