Mirki programistyczne od Javy, ale nie tylko,
chwalę się wydaniem wersji 1.0.0 biblioteki Tomoko mojego autorstwa. Zapraszam na stronę główną, gdzie zajdziecie przykłady jak i dokładny opis działania.
Każdy projekt wymaga modyfikacji danych. W przypadku REST API można skorzystać z żądań PUT lub PATCH. PUT załatwia sprawę, ale nie zawsze chcemy przesyłać cały stan zasobu, stąd i PATCH jest potrzebny. Żeby dla każdej właściwości danego zasobu nie tworzyć osobny PATCH endpoint wymyślono JSON
chwalę się wydaniem wersji 1.0.0 biblioteki Tomoko mojego autorstwa. Zapraszam na stronę główną, gdzie zajdziecie przykłady jak i dokładny opis działania.
Każdy projekt wymaga modyfikacji danych. W przypadku REST API można skorzystać z żądań PUT lub PATCH. PUT załatwia sprawę, ale nie zawsze chcemy przesyłać cały stan zasobu, stąd i PATCH jest potrzebny. Żeby dla każdej właściwości danego zasobu nie tworzyć osobny PATCH endpoint wymyślono JSON
















Łatwiej to wytłumaczyć na przykładzie matematyki. Wartość bezwzględna abs(x) jest funkcją idempotentną, ponieważ kilkukrotne jej użycie daje ten sam wynik co jednokrotne, czyli abs(abs(x)) = abs(x).
PUT ustala cały stan danego zasobu. Jeśli zaraz po sobie przyjdą dokładnie dwa takie same żądania PUT to pierwsze z nich zmiany wprowadzi, natomiast drugie już nie będzie miało czego zmieniać. Brak będzie jakichkolwiek
Klient wysyła żądanie GET o zasób i razem z nim dostaje jego aktualny ETag. Powinien gdzieś ten ETag zapisać. Po pewnym czasie zasób mógł się zmienić i klient ponownie wysyła żądanie GET, które będzie w nagłówku "If-None-Match" zawierało