[C.....J]

"Generic wildcard types should not be used in return parameters"
Czy w kontrolerach restowych złym nawykiem jest zwracanie obiektu typu wildcard? Bo generalnie jest to słaba praktyka? Pytanie jak w przypadku kontrolerów, dla przykładu mam Restowe API i wciągamy dane i zwracamy je w odpowiedzi http z jsonem. Metody z kontrolerów zwracają ResponseEntity . Pytanie czy nie lepiej od warstwy serwisowej wiedzieć co zwracamy i taki typ przyjąć w obiekcie ResponseEntity w warstwie kontrolerów?
#java #spring #niewiem

[moriturius]

@CiekawskiJ zwracaj konkretne obiekty. Nie widziałem jeszcze przypadku, który wymagałby zwracania ResponseEntity

[C.....J]

@moriturius: ja chcę zwracać response entity, ale pytanie czy typu wildcard czy konkretnego obiektu. Skoro nie widzialeś przypadku, który wymagałby zwracania ResponseEntity to jak realizujesz obsługę chociażby kodów Http albo HATEOS przy uzyciu nagłówków?

[moriturius]

@CiekawskiJ Endpointy u mnie zwracają Obiekty DTO Z @ResponseBody. Kod zwracany można określić przez @StatusCode a customer headery można CHYBA ustawiać na HttpServletResponse, które sobie zainjectujesz do metody endpointu.

[C.....J]

@moriturius: poszukałem i nie znalazlem takiej adnotacji jak @StatusCode, ew. @ResponseStatus, ale srednio mi sie to podoba bo po drodze w wartswie serwisowej mozemy chcieć zwrócić inny status niż ten zadeklarowany na kontrolerze, więc chyba zostanę przy ResponseEntity, a z tego co wyczytałem to zwracanie ResponseEntity w metodach kontrolerów jest dobrą praktyką ;)

[moriturius]

@CiekawskiJ no chodziło o @ResponseStatus :)
Dlaczego miałbyś chcieć zwracać inny status niż zadeklarowany na endpoincie?
Z jakich lat były te artykuły z dobrymi praktykami? Nie mówię że jest ona zła. Po prostu uważam, że używanie @RsponseBody jest lepsze :)

[C.....J]

@moriturius:

Dlaczego miałbyś chcieć zwracać inny status niż zadeklarowany na endpoincie?

Tak szybko co mi przychodzi do głowy to np. dla operacji asynchronicznych na zasobie. Mamy sytuację, że wywołanie danego endpointu powinno zakończyć się Http 200, ale dany request może zajmować różny czas i dla dłuższego przetwarzania requestów chcielibyśmy zwrócić klientowi Http 202, w metodzie z adnotacją @ResponseStatus byłoby to niemożliwe

Z jakich lat były te artykuły z dobrymi praktykami? Nie

[moriturius]

Mamy sytuację, że wywołanie danego endpointu powinno zakończyć się Http 200, ale dany request może zajmować różny czas i dla dłuższego przetwarzania requestów chcielibyśmy zwrócić klientowi Http 202, w metodzie z adnotacją @ResponseStatus byłoby to niemożliwe

W moim rozumowaniu to właśnie @ResponseStatus uratuje Twoje API przed pochopnymi decyzjami ;)

Dany endpoint powinien działać w jeden konkretny sposób. Klient musi wiedzieć czy dostanie odpowiedź, czy musi później o zapytać o status żądania. Taki