W tej lekcji poruszymy temat metod PUT i PATCH. Metodę PUT co prawda już poznaliśmy, ale dzisiaj zobaczysz czym się ona różni od PATCH i do czego się jej używa.
Dokumentacja do sklepu
Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.
Wersja Javy
W zależności od tego której wersji Javy używasz, mogą się pojawić drobne rozbieżności w sytuacji, w których pobieramy jakąś informację z odpowiedzi metodą get(), a następnie ją „wypluwamy” w konsoli metodą println, np.:
System.out.println(response.jsonPath().get("name"));Jeżeli nie zadziała Ci to, co pokazuję (będzie się podkreślało na czerwono i po najechaniu zobaczysz „Ambiguous method call”) możesz zamiast get() użyć metody getString():
System.out.println(response.jsonPath().getString("name"));CRUD: PUT i PATCH
Do tej pory poznaliśmy metodę PUT jako sposób na modyfikację obiektów. Po co w takim razie jest metoda PATCH i czy da się jej użyć w naszym API?
Różnice pomiędzy PUT i PATCH
Różnica pomiędzy PUTem i PATCHem jest często bardzo kosmetyczna, a w niektórych API (tak jak w przypadku naszego) żadna. Filozofia stojąca za rozróżnieniem tych dwóch metod wynika z dwóch podejść do przechowywania danych (historycznie – w bazach danych).
Jedno z podejść polega na tym, że raz dodany do bazy rekord nie jest już nigdy modyfikowany, a jeśli chcemy zmienić dane, to tworzymy rekord o tym samym ID, ale nowszej wersji (lub rewizji). W takim podejściu – jeśli pobieramy dane, to domyślnie są nam serwowane te najnowsze, chyba, że prosimy o konkretną w2rsję. Stąd jest to dobry sposób jeśli chcemy przechowywać historię obiektów. Takie podejście wspiera metoda PUT – zgodnie ze standardem zamieni ona istniejący obiekt na ten dostarczony przez nas – stworzy nową wersję obiektu.
Drugie podejście do przechowywania danych pozwala na modyfikację istniejącego obiektu – tu do głosu dochodzi PATCH. Istnieją systemy, które umożliwiają świadomym użytkownikom obie akcje – tzn jeśli chcesz stworzyć nową wersję, proszę bardzo, użyj PUTa, jeśli chcesz zmienić istniejącą – PATCH jest dla Ciebie.
A jak to jest w naszym API?
Nasze API wbrew temu co mówi dokumentacja (wymienia tylko PUTa) pozwala na modyfikację danych aż na trzy różne sposoby – działają zarówno PUT, jak i PATCH, a dodatkowo POST wysłany do konkretnego obiektu również go zmieni. Nie jest to jednak typowe podejście i radziłbym Wam zapamiętać, że jest raczej niezgodne ze standardem.
Niezależność testów
Ponieważ znamy już wszystkie potrzebne metody, sposoby ich użycia i wyciągamy uniwersalne dane poza konkretne testy to warto wspomnieć jeszcze o jednej dobrej praktyce testowania: niezależności testów! Każdy test powinien być niepowiązany z pozostałymi, testować pojedynczą (i możliwie małą funkcjonalność). Czyli na przykładzie kasowania – taki test powinien testować tylko kasowanie.
Wyobraźmy sobie jednak sytuację w której przestaje nam działać tworzenie obiektów (ten test failuje), ale kasowanie działa super. Jeśli listujemy obiekty, a potem kasujemy np. pierwszy z listy, to może się okazać, że nasze testy automatyczne skasowały wszystkie dane z systemu, a nie mamy do czasu naprawy tego błędy sposobu na stworzenie nowych. Dlatego moje podejście jest takie, że możemy wykonać więcej czynności, pamiętając jednak, że naszą główną, pożądaną asercją jest ta sprawdzająca kasowanie. Podobnie możemy podejść do zmiany obiektu. Możemy zmieniać w kółko ten sam obiekt (np. zmieniając nazwę na System.currentTimeMillis() – czyli aktualny czas wyrażony w milisekundach) albo stworzyć obiekt i sprawdzić czy taki nowo utworzony obiekt da się też zmodyfikować.
Kod z lekcji
Ukryta treść
Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.
Kolejna bardzo fajna lekcja. W 100% się zgadzam z podeściem, żeby w teście, który kasuje obiekt, najpierw go stworzyć. Dziwi mnie tylko jedna rzecz w tym API, że przy POST i PUT nie trzeba wysłać całego JSONa.
Dzięki 🙂 W sumie dobrze, że o tym wspomniałeś [...] CAŁOŚĆ KOMENTARZA WIDOCZNA DLA SUBSKRYBENTÓW.
Pięknie, dwaj prowadzący szkolenia o API nauczają w komentarzach innych poruszając ważne tematy.
Google, please index as "zdrowa konkurencja" 😀 [...] CAŁOŚĆ KOMENTARZA WIDOCZNA DLA SUBSKRYBENTÓW.