Schemat aplikacji w spring boot

Mam pytanie mam aplikację która sprawdz mi kilka linków w kilku lokalizacjach i resultat niektórych endpotów są od siebie zależne. Mam na samym konu uzyskać statusok. Między czasie jak coś bedzie nie tak to pol;eci ResponStatus z błedem
Chce zrobić to tak że wywołam głowną metodoe @GetMappingi ona będzie wywoływać mi kolejne metody np.
1 metoda zostanie wywołana i będzie ze statusem ok przekaże resultat do kolejnej metody kotra jezeli bedzie status ok wywoła kolejną metodę i to dla jednej lokalizacj
Teraz potrzebuje zrobić to dla 5 lokalizcaj. ( czyli 15 linków) I jak to rozwiązać aby to wyglądało
Czy stworzyć klasę abstrakcyjną i poźniej serwisy dla każdej lokalizacji w niej jedną głowną metodę kótra będzie wywoływać mi dziedziczone motedy z podstawionymi linkami do odpowiedniej lokalizacji i na samym końu w mertodzie w kontrolerze wywołać po kolei każdą metodę głowną z każdej lokalizacji ?

Czy jednak inaczej to zrobić ?

Bardziej niż nad jakimś dziecinnym dziedziczeniem, pomyślałbym o architekturze - te 15 linków to są serwisy Twoje? Czy to zupełnie poza waszą firmową organizacją? 15 http calli to już trochę może trwać, jest ryzyko timeoutów.

resultat niektórych endpotów są od siebie zależne

czyli nie można zrównoleglić, trzeba sekwencyjnie... hmm... no tutaj IMO największy problem może być z tym timeoutem (i w ogólności czasami oczekiwania) i pytanie czy użytkownik potrzebuje znać odpowiedź od razu czy można podejść jakoś async do tego.

to jest wenwnątrz firmy i jak będę one uruchamiana aby sprawdzić czy te ednpoty odpowiadają i czy serwery i usługi wstały . To będzie max 3 razy w miesiacu

Primo:
https://refactoring.guru/pl/design-patterns/chain-of-responsibility

Secundo: przemyśl kwestię timeoutów: strzelasz na swój endpoint X który pod spodem sekwencyjnie strzela do nastu innych, na każdym z nich może wystąpić różny czas odpowiedzi który po finalnym zsumowaniu sprawi, że strzał na endpoint X dawno się timeoutuje.

Jak jest tyle komunikacji sieciowej to imho słabo to robić w pełni synchronicznie.
Lepiej by było wysłać żądanie, zwrócić jego identyfikator, zakolejkować a potem jeszcze raz zapytać się o status na podstawie identyfikatora.

Próbuje stworzyć Beana

ale dsotaje error

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'testIcContrller': Unsatisfied dependency expressed through field 'restTemplate': Error creating bean with name 'restTemplate' defined in pl.eo.testliveic.TestLiveIcApplication: Failed to instantiate [org.springframework.web.client.RestTemplate]: Factory method 'restTemplate' threw exception with message: org/apache/hc/client5/http/impl/classic/HttpClients

Mój Bean

@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder){
    HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory();
    httpRequestFactory.setConnectTimeout(10000);
    httpRequestFactory.setConnectionRequestTimeout(10000);
    return builder.build();
}

i wtrzukuje przez
@Autowired
private RestTemplate restTemplate;

Strzelam, że zaraz po tym co wkleiłeś
threw exception with message: org/apache/hc/client5/http/impl/classic/HttpClients

jest wypisana właściwa przyczyna błędu.

W tym co wysłałeś:

@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder){
    HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory();
    httpRequestFactory.setConnectTimeout(10000);
    httpRequestFactory.setConnectionRequestTimeout(10000);
    return builder.build();
}

to na moje to te 3 pierwsze linijki metody nic nie robią, ostatecznie wychodzi to samo co

@Bean
public RestTemplate restTemplate(RestTemplateBuilder builder){
    return builder.build();
}

Z ciekawości dlaczego nie powinno wstrzykiwac się przez pole bez użycia konstruktora?

@TakMaszRacje: tego obiektu httpRequestFactory nigdzie nie używasz (na builderze wołasz build() bez ustawiania niczego).
Poczytaj jak korzystać z wzorca builder ;)

@IceBreaker:
Bo bardzo to utrudnia testowanie bo nie jesteś w stanie w prosty sposób zsetupować obiektu do testów, zmniejsza to czytelność kodu (imho) i elastyczność. Wymusza min. zabawy jeśli nagle się okaże, że masz 2 beany tego samego typu (co wcale rzadkością nie jest) bo musisz konkretnie wskazać który bean ma zostać wstrzyknięty (w springu np. poprzez ustawienie któregoś jako primary itp.

https://www.baeldung.com/java-spring-field-injection-cons

IceBreaker napisał(a):

Z ciekawości dlaczego nie powinno wstrzykiwac się przez pole bez użycia konstruktora?

To co napisał @RequiredNickname plus kiedyś byłą taka zasada, że jeśli udało się wywołać konstruktor obiektu z powodzeniem to jest on w poprawnym stanie. Potem weszła Java EE ze swoimi pomysłami i wymyślili że początek życia obiektu wygląda tak

1. Wywołąm se konstruktor, obiekt jest w stanie uj wie jakim
2. po ustawiam se wszystko przez settery. Może o niczym nie zapomnę
3. wywołam se postkonstructor vel init.Od teraz obiekt jest wrescie w stanie poprawnym

Oczywiście nie zawsze występują wszystkie fazy. A to że robi to za nas framework dużo nie pomaga bo czasem na potrzeby testów chcielibyśmy utworzyć obiekt sami

Dodatkowo ustawianie zależności przez settery sprzyja boskim obiektom gdzie obiekt ma 10 zależności i nikt nie wiedzi w tym nic złego. Gdy masz 10 zależności przez konstruktor szybciej się zorientujesz że klasa ma trochę za dużą odpowiedzialność i można by ją podzielić

Powiem więcej: nie ma sensu każdego używanego w springowych serwisach obiektu ładować jako beana do kontekstu ;)

RequiredNickname napisał(a):

@TakMaszRacje: tego obiektu httpRequestFactory nigdzie nie używasz (na builderze wołasz build() bez ustawiania niczego).
Poczytaj jak korzystać z wzorca builder ;)

@IceBreaker:
Bo bardzo to utrudnia testowanie bo nie jesteś w stanie w prosty sposób zsetupować obiektu do testów, zmniejsza to czytelność kodu (imho) i elastyczność. Wymusza min. zabawy jeśli nagle się okaże, że masz 2 beany tego samego typu (co wcale rzadkością nie jest) bo musisz konkretnie wskazać który bean ma zostać wstrzyknięty (w springu np. poprzez ustawienie któregoś jako primary itp.

https://www.baeldung.com/java-spring-field-injection-cons

Przepraszam za odkop, ale zapamietalem ten wątek z zasadą ze trzeba robic DI przez konstruktor a nie pola. Czy ta zasada dotyczy również kontrolerów w springu?

Kontroler springowy to taki sam bean jak każdy inny i tu się w kwestii dobrych praktyk nic nie zmiena.

Wstrzykiwania przez pole używam tylko w testach.