Totalnie nie w tą stronę poszedłeś:
Filtry - które ktoś wybiera np. użytkownik (jak napisałeś) po stronie interfejsu i tzw. stronie klienckiej, twoja aplikacja - traktuje jako DANE tylko i wyłącznie, tzn. są to "funkcje", dane obiektu, elementy zapytania które potem mają być przetwarzane.
Bez znaczenia czy przekażesz je jako RequestParam, czy jako RequestBody etc. dalej masz do czynienia z oczekiwanym obiektem" który ma mieć, oczekiwane, wybrane właściwości".
Teraz jedyna rola jaka spoczywa na Controlerze ( zależy od architektury ) to VALIDACJA czy obiekt jest zgodny z oczekiwanym ( czy posiada wymagane pola, odpowiedni format itd). I teraz jeśli zależnie od architektury- korzystasz z podziału na Controlery i Serwisy - to wtedy LOGIKA BIZNESOWA - czyli walidacja dokładnie tych danych powinna mieć miejsce w Serwisach, natomiast sam Controler może walidować tylko parametry zapytania ( czy posiada odpowiedni obiekt i wypełnione pola, bez wglądu na to czy pola sa prawidlowe czy nie), oraz Controler moze sprawdzać czy - nagłówki są okej, czy klient ma takie i nie inne funkcje ( czyli autoryzacja i identyfikacja uzytkownika sesji).
Dalej ... idąc ostatnim punktem który realizujesz to walidacja filtrów czy są takie i wybrane w Serwisie a dalej jedynie to już kwestia przesłania ich i zbudowania odpowiedniego zapytania do bazy z poziomu Serwisu ( logiki biznesowej).
Baza danych ma miec juz w calosci przygotowane zapytanie i nie potrzebuje walidacji a wręcz nie powinna.
To jak zbierzesz filtry, czy wykorzystasz Criteria Api,( które jest okej, ale nie jest bez wad), czy może skorzystasz z Natywnych Query i sam będziesz budował czy nawet spróbujesz użyć SPECYFIKACJI, które są bardzo wadliwe jeśli nie są dobrze przygotowane dane i dobrze zbudowana struktura Encji
https://spring.io/blog/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/.
Wady i zalety są każdych rozwiązań, nie ma lepszego i gorszego jak na razie rozwiązania o ile nie powoduje ono dodatkowych implementacji funkcji ( komplikowania kodu, tworzenia SILNYCH POWIĄZAŃ MIEDZY KLASAMI ITP).
A co do doświadczenia: to wszystko zależy od FLOW projektu i architektury którą zastosowałeś: tak aby trzymać się jednolitych rozwiązań i spójności.
Istotnie niewielkie różnice w implementacji rzeczy Controler vs Swerwis mogą mieć istotny wpływ na jakość/trudność i performance pisania testów w przyszłości
