Spring Web vs Data REST

W ramach treningu tworzenia REStowego API którą zależność lepiej zaciągnąć do projektu, Web Service czy Data Rest? Pytam, ponieważ jestem "totalnym amatorem" i ogólnie lepiej czuję się pisząc w Webie, ale np. gdy chcę stworzyć dla api statusy http + linki (hateoas) to pisząc w webie wychodzi mi sporo linijek zagmatwanego kodu który nie do końca jest dla mnie zrozumiały, zaś pobierając spring data rest mam praktycznie wszystko od razu zrobione. Jak to wygląda w praktyce, w pracy ?

Jeszcze dodatkowe pytanie, czy ma ktoś jakieś materiały gdzie dość prosto tłumaczą jak tworzyć dto?

Java91 napisał(a):

Jeszcze dodatkowe pytanie, czy ma ktoś jakieś materiały gdzie dość prosto tłumaczą jak tworzyć dto?

W projektach naprawdę dużych, gdzie encje bazodanowe a biznesowe maja wyraźnie odmienną budowę, potrzeba na DTO jest oczywista (a spsoób ich projektowania ... to doświadczenie)

W ćwiczebnych /szkolnych CRUD-ach dość trudno jest stanąć w takiej pozycji, żeby potrzeba na wydzielanie DTO jest wyrazista - najczęściej okaże się, że pole w pole pokrywa się z encją, i pojawia się niepewnosć "po co"

ZrobieDobrze napisał(a):

Java91 napisał(a):

Jeszcze dodatkowe pytanie, czy ma ktoś jakieś materiały gdzie dość prosto tłumaczą jak tworzyć dto?

W projektach naprawdę dużych, gdzie encje bazodanowe a biznesowe maja wyraźnie odmienną budowę, potrzeba na DTO jest oczywista (a spsoób ich projektowania ... to doświadczenie)

W ćwiczebnych /szkolnych CRUD-ach dość trudno jest stanąć w takiej pozycji, żeby potrzeba na wydzielanie DTO jest wyrazista - najczęściej okaże się, że pole w pole pokrywa się z encją, i pojawia się niepewnosć "po co"

Z tego co piszesz to chyba lepiej zostać na Webie?:)

ZrobieDobrze napisał(a):

W projektach naprawdę dużych, gdzie encje bazodanowe a biznesowe maja wyraźnie odmienną budowę, potrzeba na DTO jest oczywista (a spsoób ich projektowania ... to doświadczenie)

a kiedy jest projekt duży, a kiedy mały?
raczej się nie zgodzę... dto powinny być robione wszędzie gdzie jestt jakakolwiek, choćby najmniejsza, logika biznesowa.
Przykład:

POST .../documents

użytkownik przy tworzeniu może podać sygnaturę. Jeśli nie podba to należy zapisać domyślną wartość sygnatury XXX.
Potrzebujesz do tego dto.
Za chwilę przyjdzie kolejne wymaganie: jeśli użytkownik z Radomia to sygnatura ma być RXXX, chyba, że użytkownikiem jest osoba prawna z zarejestrowana minimum 2 lata to wtedy RRXX itd.
Jak nie masz dto to potem czas na każdą kolejną taką zmianę będzie rosnąć wykładniczo zamiast być stały.

@LitwinWileński:

Nie kumam argumentacji. Piszesz o logice, logika to encja biznesowa, i to normalne zlecenia biznesowe

Co więcej, (nadmierna) ilość warstw, to trudność np jak najwcześniejszego walidowania.

Jak dla mnie Encja biznesowa to obiekt. Logika biznesowa to zachowanie.
Walidacja to raczej logika biznesowa, chyba ze sama poprawbosc wartosci sprawdzasz np. czy email to email to mozesz na dto.

@LitwinWileński:

Chlopak pyta o start, a tym mu DDD.

BTW DDD jest odradzane przez uczciwych wykładowców, jeśli nie ma ku temu rzeczywistych powodów np w złożoności projektu.

To jeszcze nie ddd tylko architektura hexagonalna.
W javie nie pisze sie innych projektow jak zlozonych. Jak masz nie zlozony projekt, a do tego prototypujesz to pisz w czym innym

LitwinWileński napisał(a):> To jeszcze nie ddd tylko architektura hexagonalna.

W javie nie pisze sie innych projektow jak zlozonych. Jak masz nie zlozony projekt, a do tego prototypujesz to pisz w czym innym

Nie znałem tej religii

LitwinWileński napisał(a):

To jeszcze nie ddd tylko architektura hexagonalna.

Która jest o wiele za dużo w tutejszym kontekście.

ZrobieDobrze napisał(a):

LitwinWileński napisał(a):> To jeszcze nie ddd tylko architektura hexagonalna.

W javie nie pisze sie innych projektow jak zlozonych. Jak masz nie zlozony projekt, a do tego prototypujesz to pisz w czym innym

Nie znałem tej religii

nie piszesz w hexagonalnej? to po co Ci język (prawie) obiektowy taki jak java? Musisz mieć straszny syf w projekcie albo rzeczywiście same CRUDy.

LitwinWileński napisał(a):

ZrobieDobrze napisał(a):

LitwinWileński napisał(a):> To jeszcze nie ddd tylko architektura hexagonalna.

W javie nie pisze sie innych projektow jak zlozonych. Jak masz nie zlozony projekt, a do tego prototypujesz to pisz w czym innym

Nie znałem tej religii

nie piszesz w hexagonalnej? to po co Ci język (prawie) obiektowy taki jak java? Musisz mieć straszny syf w projekcie albo rzeczywiście same CRUDy.

Powiem ci, jest jeszcze gorzej.
Np skrajnie rzadko w Springu.

akurat Spring to mocno łamie założenia architektury hexa przez wyciekające abstrakcje

@LitwinWileński: temat powoli zaczyna się łączyć z "Jak rozwiązujecie różnice zdań przy review?" :)
Chłopak pyta o X, wy gadacie tu o Y, mieszając wiele rzeczy razem.

Jeśli chcesz zrobić projekt na szybko, albo masz mało doświadczenia jak dobrze zrobić CRUDa używając weba, a potrzebujesz mieć API na już, to poszedłbym w Data REST. Tylko potem utrzymanie tego może być trochę upierdliwe, bo on z automatu dorzuca dużo featurów, które można niechcący wypuścić w świat, zmiana ich też wymaga poznania dodatkowych adnotacji.

Web jest prosty. W pracy rzadko kiedy potrzebujesz mieć HATEOAS.

@Productionserver:
Dzięki za odpowiedź a czy przy tworzeniu resta statusy http typu 201 created 202 accepted itp są często wykorzystywane w pracy?

Zależy od ustaleń w zespole. U mnie teraz prawie same 200 latają. Ale jak pracowałem w UPC to tam poważnie podchodzili do kodów i 201 było częste