Asynchroniczna komunikacja - podstawy.

Witajcie,
Zadaję pytanie z prośbą o nakierowanie kierunku nauki w temacie asynchronicznej wymiany komunikatów.
W 'Spring in action' autor zaczyna omawianie działu od ActiveMQ.
Nie chcę uczyć się przestarzałych narzędzi, zatem proszę o pomoc: czego powinienem się dowiedzieć i jakich narzędzi się nauczyć używać w celu połączenia mojego RESTful web service napisanego w Springu z klientem napisanym w Angularze (Web Service jest gotowy, a klient jest powiedzmy przygotowany, ale potrzebuje danych z API).

Pozdrawiam was!
I nie nabijajcie się ze mnie, bo już czara goryczy została przelana xD

Nie rozumiem pytania. Skoro masz już RESTowy endpoint w backendzie to czego ty szukasz? Podpinasz się Angularem pod ten endpoint i tyle.
Komunikacja asynchroniczne jest do zupełnie innych celów i na linii backend-frontend to sie raczej słabo sprawdzi.

Asynchronicznie komunikuje się zwykle backendowe serwisy które wykonują jakieś "ciężkie" akcje i kiedy jednocześnie nie potrzebujemy od razu mieć wyników. Załóżmy że piszesz jakiś crawler, który wchodzi na stronę, analizuje ją, indeksuje zawartość, pobiera linki i crawluje potem te pobrane linki.
Mógłbyś napisać tutaj 2 komponenty -> jeden który wchodzi pod podany linki i pobiera jego zawartość i drugi który zajmuje się indeksowaniem i wyciąganiem interesujących informacji z zawartości.
Takie dwa komponenty można komunikować asynchronicznie, bo przecież nie ma sensu żeby ten pierwszy czekał aż się coś zaindeksuje, żeby wysłać kolejny content.

Dzięki za odpowiedź. W takim razie kompletnie nie zrozumiałem tematu. Jeszcze chwilę temu myślałem, że do komunikacji server - client będę potrzebował czegoś takiego jak Kafka czy RabbitMQ.

W takim razie, może mi ktoś w jednym zdaniu powiedzieć do czego służą te narzędzia oraz WebSocket i Stomp ? Bo z książki tak nie bardzo łapię jakie jest przeznaczenie tych technologii.

Websockety to jest fajna rzecz jeśli chcesz np. w czasie rzeczywistym (lub zbliżonym) odświeżać wyniki. Wyobraź sobie że piszesz frontend dla operatorów elektrowni atomowej. Oni by chcieli zeby na ekranie cały czas wyświetlały się aktualne wartości z czujników ciśnienia, temperatury itd. Bez sensu byłoby co chwila robić ajaxowy request żeby te wyniki pobrać, prawda? Szczególnie, że ilość przesłanych danych z endpointu byłaby wielokrotnie mniejsza niż rozmiar requestu. No i to i tak robiłbyś pewnie raz na kilka sekund żeby nie usmażyć przeglądarki.
Websockety pozwalają na nawiązanie połączenia a potem przesyłanie danych bez potrzeby wysyłania kosztowych requestów ani bawienia się w jakieś pobieranie danych raz na kilka sekund. Klasyczna różnica między modelem push i pull.
Co więcej po stronie klienta ty sobie po prostu czytasz dane kiedy przychodzą i nie musisz wiedzieć jak często będą przychodzić. Każdy "dostawca" sam to sobie ogarnia. Gdybyś te dane pullował requestami to musiałbyś po stronie klienta wiedzieć jak często odpytywać każdy endpoint. No i websockety pozwalają też na komunikacje w 2 strony!

@Shalom: Dzięki za odpowiedź. Ale jeśli mogę: czy uważasz, że robiąc pierwsze API powinienem się tego uczyć? Czy raczej zostawić to na bardziej odpowiedni czas?

To już zależy od zastosowania. Dobiera sie technologię do problemu. REST, Websocket ani jakakolwiek inna technologia to nie jest silver bullet ani panaceum. To są rzeczy które pasują w jednym miejscu a w innym nie. Niestety wielu ludzi stosuje podejście jak mam młotek to nagle wszystko wygląda jak gwoździe.
Nie ma tu znaczenia czy to 1 czy 100 API. Ma znaczenie problem który chcesz rozwiązać.