Jakie powinno być response POST/PUT/DELETE i gdzie konwersja DTO?

Cześć, mam dwa pytania. :)

1. Co powinny zwracać controllery w metodach POST, PUT, DELETE?

Zauważyłem, że nie używam za bardzo responsów z POST/PUT/DELETE, więc równie dobrze można by tam chyba jakiegoś voida wrzucić.

2. Czy metody serwisowe GET powinny zwracać DTO czy Entity, to znaczy: konwersja z Entity na DTO powinna się odbywać w kontrolerze czy serwisie?

1. Jesli nie za bardzo uzywasz responsow, to moze chociaz jakas informacje o tym czym operacja sie powiodla? Generalnie powinienes zwrocic to, czego oczekuje klient korzystajacy z API. Jesli jest to API REST'owe publiczne, to sa pewne standardy i konwencje
2. Co rozumiesz przez DTO i Entity? Ja robie tak, zeby po zmianie protokolu wysylania informacji, nie modyfikowac serwisow. W moim rozumieniu DTO to cos, co opakowywuje obiekt domenowy w obiekt ktory posiada informacje dotyczaca transportu - np wersja protokolu, format danych, endpoint ID itp. Zazwyczaj jest to cos pomiedzy serwisem i kontrolerem ale zdecydowanie blizej do tego 2giego

post: http 201 lub kod błędu np. 422 + LocationHeader + opcjonalnie jakieś body z opisem błędów (jeśli sa takie)
put: 204/kod błędu + potencjalny opis błędów
delete: 204/kod błędu + potencjalny opis błędów

Jesli piszesz todo-liste to możesz zwracać nawet w kontlolerze. Jak masz aplikacje z logiką to:
1)Repozytoria, providery etc pobierają encje biznesową (nie mylic z encją bazodanową!). One na poziomie implementacji szczegółowej mogą miec jakieś DTOsy np. encje JPA albo DTOsy na JSONy/XMLe z Rest API
2)Use Cas'y/Serwisy biznesowe operują na encjach domenowych
3)Kontrolery przyjmują z UC/Serwisów obiekty domenowe i mapuja na swoje DTOsy (jeśli potrzeba)

@pedegie:

1).

Właśnie do tej pory używałem ~zawsze coś typu "status response", który zawierał Boolean success i Message np. "Added animal successfully".

Doszedłem do wniosku, że ten Boolean success się nie za bardzo przydaje, bo sam status 2xx raczej świadczy o sukcesie. Idąc dalej: message też niekoniecznie się przydaje, bo front mógłby sobie sam message budować na podstawie statusu.

Myślałem więc, żeby jednak nie zwracać takich "status responsów", tylko w zamian np. DTO. Tylko za bardzo nie wiem po co, skoro front i tak by nie używał tego responsa.

Stąd doszedłem do tego, czy by po prostu voida nie zwracać - nie wiem jak to inni robią.

2).

Poprzez Entity mam na myśli objekty domenowe, których klasy mają @Entity, a poprzez DTO mam na myśli to co leci z powrotem na front (czyli wrapper na encję, ale bez niektórych danych lub z dodatkowymi danymi).

@Xorxorxor: albo obiekt domenowy albo encja bazodanowa - bo to są zupełnie inne rzeczy! No chyba że u jakis fanatyków JEE, ale lepiej takim nie być ;]

@Xorxorxor: No to zostaw sam status, skoro nie potrzebujesz nic wiecej zwracac :)

Co do samej konwersji, zerknij tutaj: Kiedy konwertować na DTO?

Xorxorxor napisał(a):

@pedegie:

Doszedłem do wniosku, że ten Boolean success się nie za bardzo przydaje, bo sam status 2xx raczej świadczy o sukcesie. Idąc dalej: message też niekoniecznie się przydaje, bo front mógłby sobie sam message budować na podstawie statusu.

Myślałem więc, żeby jednak nie zwracać takich "status responsów", tylko w zamian np. DTO. Tylko za bardzo nie wiem po co, skoro front i tak by nie używał tego responsa.

1. Nie zawsze to front czyta, czasem coś innego, jakiś algorytm, to zależy.
2. Teoria nie mówi, ale praktyka czasem wskazuje: tworzysz POST z kilku/nastu danych obiekt, który ma mdziesiąt właściwości i zostaną magicznie przyjęte, nie chciałbyś być o tym poinformowany? Zwłaszcza tak prozaiczne (i zgodne z zasadą wyciekających abstrakcji ;) ) jak ID / GUID ?

Takie API spotkałem w Wordpresie - daleki jestem by uważać to za najlepsze API. Np kręcił mi przy aktualizacji PUT, podmieniał zaskakująco wartości niektórych pól - ale zarazem sam pozwolił na ten ficzer/błąd się dostosować. Ale to API raczej przeznaczone dla algorytmów / integracji niż frontu. Np używane znacznie rzadziej i wydajność mniej boli.