Pod każdym pytaniem wypisałem poprawną odpowiedź. Zachęcam do samodzielnego przetestowania podanych rozwiązań, tak by je dobrze zrozumieć i zapamiętać.
Lista pytań
- Czym się różni PUT od PATCH?
- Czy metody HTTP: POST i DELETE są idempotentne?
- Wyjaśnij pojęcie „bezstanowości” w REST API i jego znaczenie dla testowania
- Jak testować API bez użycia narzędzi (np. Postmana)?
- Czy potrafisz podać jedną różnicę pomiędzy RESTful API, a Event-Driven API?
- Czy REST API musi zawsze zwracać JSON?
- Co się stanie, jeśli metoda PATCH zostanie użyta do aktualizacji nieistniejącego zasobu?
Lista odpowiedzi
Klasyka rekrutacji – czym się różni PUT od PATCH?
Odpowiedź jest krótka i konkretna:
- PUT zazwyczaj służy do pełnej aktualizacji zasobu, co oznacza, że przekazywane dane powinny w całości zastąpić istniejące dane zasobu.
- PATCH służy do częściowej aktualizacji, gdzie przesyła się tylko te pola, które mają zostać zmienione.
Czy metody HTTP: POST i DELETE są idempotentne?
To nieco podchwytliwe pytanie, ponieważ zakłada, że wiesz czym jest idempotentność w kontekście HTTP. W największym uproszczeniu oznacza, że niezależnie od liczby powtórzeń, efekt wywołania pozostaje taki sam.
DELETE: Jest idempotentny
Wywołanie metody DELETE kilka razy na tym samym zasobie ma taki sam skutek, jak wywołanie jej raz — zasób zostaje usunięty lub już go nie ma.
POST: Nie jest idempotentny
… ponieważ każde wywołanie tej metody może tworzyć nowy zasób lub wykonywać inną akcję, zmieniając stan serwera za każdym razem.
Przykład: wywołanie POST /users z danymi użytkownika może stworzyć za każdym razem nowego użytkownika (np. o unikalnym ID).
Wyjaśnij pojęcie „bezstanowości” w REST API i jego znaczenie dla testowania
Odpowiedź: bezstanowość (stateless) w REST API oznacza, że każdy żądanie klienta do serwera jest niezależne i nie przechowuje informacji o wcześniejszych żądaniach. Serwer nie pamięta stanu sesji użytkownika, co wymusza przesyłanie wszystkich potrzebnych danych (np. tokenów uwierzytelniających) w każdym żądaniu.
Na co powinniśmy zwrócić uwagę podczas testów?
Każde żądanie musi zawierać wszystkie wymagane dane (np. tokeny autoryzacyjne, parametry), testy nie mogą polegać na wcześniejszych żądaniach. Testy powinny sprawdzać, czy brak tych danych skutkuje odpowiednim błędem (np. 401 Unauthorized).
Jak testować API bez użycia narzędzi (np. Postmana)?
Odpowiedź: można testować API używając np. curl: To narzędzie wiersza poleceń pozwala na wysyłanie różnych typów żądań HTTP (GET, POST, PUT, DELETE) i analizowanie odpowiedzi bezpośrednio w terminalu.
Czy potrafisz podać jedną różnicę pomiędzy RESTful API, a Event-Driven API?
Przykładowa odpowiedź:
RESTful API nadaje się do aplikacji, gdzie interakcje są oparte na operacjach na zasobach w odpowiedzi na konkretne żądania użytkownika. Interfejsy API RESTful są synchroniczne, co oznacza, że każde żądanie czeka na odpowiedź, zanim przejdzie dalej. Na przykład, jeśli kupujesz coś z pomocą aplikacji e-commerce, każde żądanie (takie jak pobranie cen produktów, pobranie zawartości koszyka) jest przetwarzane i odpowiadane sekwencyjnie.
Event-driven API jest używane w aplikacjach wymagających reakcji w czasie rzeczywistym na zmiany w systemie, gdzie zdarzenia wyzwalają działania – np. aplikacje finansowe (np. śledzenie kursów akcji), aplikacje IoT, platformy komunikacyjne. Komunikacja odbywa się są asynchronicznie. Na przykład – podczas przesyłania pliku serwer powiadamia klienta o zakończeniu przesyłania, umożliwiając równoległe kontynuowanie innych procesów.
Czy REST API musi zawsze zwracać JSON?
Odpowiedź brzmi: Nie, nie musi, choć w praktyce JSON jest najczęściej używany, ponieważ jest lekki, łatwy do odczytu przez ludzi i maszyny oraz dobrze wspierany przez wiele języków programowania.
REST API może zwracać inne formaty danych, takie jak XML, czy czysty tekst.
Co się stanie, jeśli metoda PATCH zostanie użyta do aktualizacji nieistniejącego zasobu?
Odpowiedź: zachowanie serwera w przypadku metody PATCH dla nieistniejącego zasobu może zależeć od implementacji API, jednak serwer zazwyczaj zwróci kod statusu HTTP 404 (Not Found), informując, że zasób, który próbujesz zaktualizować, nie istnieje. Niektóre implementacje mogą traktować PATCH jako operację „utwórz lub zaktualizuj” i w odpowiedzi zwrócić kod 201 (Created).
