Pytania rekrutacyjne z projektowania API (Senior) z odpowiedziami

75 pytań na rozmowę rekrutacyjną z tematu Projektowanie API (Senior) - z poprawnymi odpowiedziami, wyjaśnieniami i linkami do dokumentacji.

Rozwiąż ten test
  1. 1.Jak wybierać między REST, GraphQL i gRPC dla nowego systemu?
  2. 2.Czym jest podejście „API jako produkt”?
  3. 3.Po co wprowadzać governance API (style guide, przeglądy, linting) w organizacji z wieloma zespołami?
  4. 4.Jak prawo Hyruma i zasada „bądź konserwatywny w tym, co wysyłasz” współgrają przy ewolucji API?
  5. 5.Jak działa wersjonowanie API według daty (jak w Stripe)?
  6. 6.Jaki jest główny koszt obsługi wielu wersji API naraz?
  7. 7.Jak bezpiecznie usunąć szeroko używane pole?
  8. 8.Dlaczego zmiana domyślnego zachowania (np. domyślnego rozmiaru strony) to zmiana niekompatybilna?
  9. 9.API zapisuje do bazy głównej, a odczyty obsługuje z replik. Klient tworzy element i od razu pobiera listę, nie widząc go. Jak projekt API powinien to uwzględnić?
  10. 10.Jak udostępnić w API wieloetapową operację obejmującą kilka serwisów?
  11. 11.Jak powinny zachowywać się klucze idempotencji, gdy pierwsze żądanie jeszcze trwa, a przychodzi ponowienie?
  12. 12.Jak długo serwer powinien przechowywać klucze idempotencji?
  13. 13.Jaki problem rozwiązuje projekt webhooków z „cienkimi” zdarzeniami?
  14. 14.Jak system webhooków powinien obsłużyć subskrybenta, który zawodzi od kilku dni?
  15. 15.Jakie jest ryzyko wysyłania webhooków na dowolne URL-e podane przez klientów?
  16. 16.Jak zaprojektować endpoint, którego zapytanie jest kosztowne i popularne?
  17. 17.Co SLO dla opóźnienia p99 API oznacza dla jego zależności?
  18. 18.Jak publiczne API powinno chronić się przed nadużyciami i kosztownymi wzorcami użycia?
  19. 19.Czym jest limitowanie żądań oparte na koszcie?
  20. 20.Dlaczego HTTP/2 zmienia kompromisy batchowania wielu małych żądań API?
  21. 21.Dlaczego persisted (dozwolone) zapytania są cenne dla publicznych API GraphQL?
  22. 22.Jak schemat GraphQL powinien modelować mutacje dla wygody klientów?
  23. 23.Jakie jest ryzyko udostępnienia modeli bazy bezpośrednio jako schematu GraphQL?
  24. 24.Dlaczego introspekcja bywa wyłączana w publicznym API GraphQL na produkcji?
  25. 25.Jakie są zasady wstecznej kompatybilności wiadomości Protocol Buffers?
  26. 26.Jakie funkcje gRPC wykraczają poza typowe REST API?
  27. 27.Jak udostępnić serwis gRPC przeglądarkom i klientom REST bez duplikowania logiki?
  28. 28.Czym różnią się OWASP API1 (BOLA) i API5 (Broken Function Level Authorization)?
  29. 29.Przed czym ostrzega OWASP API6:2023 (Unrestricted Access to Sensitive Business Flows)?
  30. 30.Czego dotyczy OWASP API9:2023 (Improper Inventory Management)?
  31. 31.Co obejmuje OWASP API10:2023 (Unsafe Consumption of APIs)?
  32. 32.Dlaczego tokeny dostępu JWT dla API trzeba weryfikować rygorystycznie?
  33. 33.Co dodaje wzajemny TLS (mTLS) dla API między serwisami?
  34. 34.Jak API może zminimalizować skutki wycieku danych uwierzytelniających?
  35. 35.Które metryki najlepiej opisują kondycję API z punktu widzenia konsumenta?
  36. 36.Jak definiować SLO dla publicznego API?
  37. 37.Po co przekazywać nagłówki W3C traceparent przez API?
  38. 38.Jak bezpiecznie wdrożyć ryzykowną zmianę API?
  39. 39.Czym jest wzorzec „długiej operacji” w wytycznych API Google?
  40. 40.Jaki problem rozwiązują „maski pól” w operacjach aktualizacji?
  41. 41.Dlaczego API może używać zorientowanych na zasoby „metod własnych”, np. POST /orders/42:cancel?
  42. 42.Jak zaprojektować paginację dla feedu, który musi pozostać spójny, gdy przychodzą nowe elementy?
  43. 43.Jak dobrze udostępniać kosztowne agregaty, np. miesięczny przychód na klienta?
  44. 44.Jak API może wspierać klientów mobilnych w podejściu offline-first?
  45. 45.Jaki jest kompromis udostępnienia ogólnego API zapytań (np. filtrów OData lub surowego dostępu GraphQL do wszystkich danych)?
  46. 46.Dlaczego „gadatliwe” wewnętrzne API mogą stać się problemem w mikroserwisach?
  47. 47.Jaka jest wada umieszczania zbyt dużej logiki w bramce API?
  48. 48.Jak API powinno obchodzić się z danymi osobowymi, żeby spełniać wymagania jak RODO?
  49. 49.Dlaczego API powinno unikać sekwencyjnych, łatwych do zgadnięcia identyfikatorów dla wrażliwych zasobów nawet przy działającej autoryzacji?
  50. 50.Jak wielodostępne API powinny zapobiegać wyciekom danych między tenantami?
  51. 51.Jak wybierać między webhookami, SSE, WebSocketami i odpytywaniem do dostarczania aktualizacji?
  52. 52.Jak API czasu rzeczywistego powinno wracać po rozłączeniach bez gubienia zdarzeń?
  53. 53.Po co dokumentować API czasu rzeczywistego i API zdarzeniowe przez AsyncAPI?
  54. 54.Czym jest consumer-driven contract testing?
  55. 55.Jak wykryć, którzy klienci się zepsują, zanim zmienisz zachowanie API?
  56. 56.Dlaczego ponowienia na kilku warstwach (klient, bramka, serwis) mogą wywołać „burzę ponowień”?
  57. 57.Czym jest hedging żądań i kiedy jest odpowiedni?
  58. 58.Jak API powinno poinformować, że żądanie zostało zastosowane częściowo i nie można go bezpiecznie ponowić?
  59. 59.Co znaczy projektowanie API „z zewnątrz do środka” (outside-in)?
  60. 60.Po co dostarczać oficjalne SDK obok dokumentacji surowego HTTP?
  61. 61.Jakie jest ryzyko ścisłego powiązania kształtu odpowiedzi API z jednym ekranem UI?
  62. 62.Jak traktować niekompatybilne zmiany formatu błędów?
  63. 63.Kiedy API potrzebuje domyślnie jawnej optymistycznej współbieżności (ETagi/If-Match)?
  64. 64.Dlaczego timeouty powinny być częścią udokumentowanego kontraktu API?
  65. 65.Jak zastąpić przestarzałe API nową implementacją bez przełączenia „wszystko naraz”?
  66. 66.Czym są planowane „brownouty” przy wycofywaniu wersji API?
  67. 67.Jak nie dopuścić, żeby jeden duży tenant pogorszył wspólne API dla wszystkich?
  68. 68.Kiedy API może oferować Protobuf lub inny format binarny obok JSON?
  69. 69.Jakie jest ryzyko cache'owania uwierzytelnionych odpowiedzi API w CDN?
  70. 70.Dlaczego API zdarzeniowe zwykle obiecują dostarczanie „co najmniej raz”, a nie „dokładnie raz”?
  71. 71.Do czego służy rejestr schematów w API zdarzeniowych (np. z Kafką)?
  72. 72.Co dodaje podpisywanie żądań (np. oparte na HMAC, jak AWS SigV4) ponad bearer token?
  73. 73.Jak projekt API powinien uwzględniać wymagania dotyczące lokalizacji danych (np. dane z UE zostają w UE)?
  74. 74.Dlaczego tokeny paginacji powinny być powiązane z zapytaniem, które je wygenerowało?
  75. 75.Gdzie dokumentować kwoty i limity żądań dla każdego planu?