[nick230]

Mireczki pytanko o resta i metodę patch.

1. Mam walidację pól w entity. Robiąc częściowy update obiektu, niektóre pola zostają te same, więc w jsonie leci "niepełny" obiekt i nie skonwertuje tego na docelowe entity, jak rozwiązać problem z walidacją? Stworzyć DTO ze wszystkimi optional polami (no poza tymi, które są niezbędne do obiektu) i potem robić osobną walidację w jakimś serwisie i to co przeszło walidację dodać do entity? Jakie jest najpopularniejsze podejście do tego?

2. Jak jesteście zalogowani w jakimś sklepie i w ustawieniach konta chcecie usunąć kilka swoich danych typu adres, karta kredytowa, numer telefonu. Jak wysyłając patcha i walidując odróżnić wartość pola niespełniającego reguły np. kod pocztowy 23423---323 od usunięcia swoich danych czyli w requeście leci empty/null? To pierwsze powinno nie przejść walidacji, to drugie w sumie tak, bo chce usunąć dane.

#programowanie #programista15k #java #spring

[MrFisherman]

@nick230: 2. A tak się w ogóle robi? Usuwa dane patchem? Czemu nie wysyłając normalnie delete?

[Blomex]

@nick230: po co używać patch?( ͡° ͜ʖ ͡°)

[nick230]

@Blomex: To czego? Put do całościowego updatu służy

[nick230]

A tak się w ogóle robi?

@MrFisherman: Nie wiem, pytam xD

Czemu nie wysyłając normalnie delete?

Nie chce usunąć konta, tylko parę danych z mojego profilu.

[nick230]

The HTTP PATCH method should be used whenever you would like to change or update just a small part of the state of the resource. You should use the PUT method only when you would like to replace the resource in its entirety.

[famir96]

taktyk

[zibizz1]

@nick230: nie wiem jak w javie ale w jsonie
NazwaPola: null
Może być traktowane jako usunięcie danych

[k.....5]

@nick230:
Jeśli chodzi o drugi podpunkt, to chyba zależy jak ktoś to wymyślił ( ͡° ͜ʖ ͡°)
Jak masz adres/kartę jako zasób i chcesz go usunąć, to wysyłasz DELETE.
Jak numer telefonu jest częścią profilu, to PATCH/PUT w zależności ile pozwalasz modyfikować. Jeśli adres byłby częścią profilu, to wtedy go modyfikujesz, a nie usuwasz - więc PATCH/PUT, a nie DELETE.
Jeśli chodzi o walidację tego przykładowego kodu

[b.....r]

. Mam walidację pól w entity. Robiąc częściowy update obiektu, niektóre pola zostają te same, więc w jsonie leci "niepełny" obiekt i nie skonwertuje tego na docelowe entity, jak rozwiązać problem z walidacją? Stworzyć DTO ze wszystkimi optional polami (no poza tymi, które są niezbędne do obiektu) i potem robić osobną walidację w jakimś serwisie i to co przeszło walidację dodać do entity? Jakie jest najpopularniejsze podejście do tego?

@nick230: podbijam

[zenek1998]

@nick230: raczej bym zrobił tak:

- GET zwraca obecne dane np. adres.
- Klient wyświetla te dane użytkownikowi.
- Użytkownik wprowadza zmiany i klika submit.
- PUT wysyła wszystkie dane czyli to co z GET z naniesionymi zmianami
- następuje standardowa walidacja jak przy np. POST

[nick230]

@zenek1998: Dokładnie tak przez dłuższy czas czas kiedyś robiłem. Teraz wracam do resta i czytam sobie w necie, że tak ludzie robią ( ͡º ͜ʖ͡º)

[draxgar]

@nick230: Masz wiele opcji, niektóre lepsze niektóre gorsze. Która jest lepsza i gorsza zależy od wymagań systemu.
Możesz walidować jak w POST, możesz zrobić sobie różne DTO na okazję PATCH i PUT. Możesz Adnotować @Nullable i @Pattern. Możesz stworzyć własny walidator.
Zauważ, że PUT w założeniach służy do utworzenia nowego obiektu, PATCH zmiany istniejącego, a do reszty POST, który może służyć do utworzenia nowego jak i naniesienia zmian na istniejący

[PaaD]

@nick230:

1) Wygląda na skutek pójścia na skróty w projektowaniu architektury poprzez pchanie encji aż do międzymordzia. Mając rozdzielone warstwy i posługując się w endpointach tylko TO, problem prawdopodobnie rozwiąże się sam.

2) Nie sprawdzałem, ale możesz sprawdzić czy w przypadku Jacksona użycie Optional w TO nie zapewni rozróżnienia pomiędzy null a empty.

[nick230]

posługując się w endpointach tylko TO

@PaaD: TO?

[PaaD]

@nick230: Transfer Object