Зависит от того что именно за данные (для какой цели) будут передаваться и между кем и кем.
Rest как и любой другой синхронный метод взаимодействия несёт плюсы:
+ Сравнительно быстрая реакция на запрос и ответ. (как правило от запроса до получения ответа менее секунды)
+ Очень прост в использовании, нет никаких проблем с поддержкой на клиенте
+ Очень простая инфраструктура (в минимальном варианте она не нужна вообще)
+ Всё хорошо изучено. Та же аутентификация и авторизация очень легко реализуется в рамках http.
+ Достаточно легко разрабатывать и тестировать
+ Есть grpc и openapi - нет никакой проблемы с документированием такого API.
+ В http запрос с каким-нибудь multipart form data может спокойно быть размером в десятки мегабайт, а может и больше - полезно при загрузке файлов.
И минусы:
- Не понятно что делать, в случае недоступности ответной стороны
- При неправильной реализации клиента (политики ретраев) - можно легко заддосить сервер
Всякие разнообразные брокеры сообщений тоже имеют свои плюсы:
+ Строгая очерёдность обработки данных (событий) из коробки
+ В случае недоступности ответной стороны - брокер у себя может хоть несколько дней держать данные
+ Все политики ретраев реализуются на стороне брокера
+ Если это rabbit, то можно разные сложные механики рассылки и маршрутизации реализовать
+ Если это кафка или какой-то другой лог, то можно вычитывать события повторно
Но есть и минусы:
- Инфраструктура обычно сложнее
- Достаточно большие задержки
- Использовать можно будет только у себя внутри - внешнему клиенту (браузер, мобильное приложение, публичный API) такое дать не получится.
- Сложнее разграничивать в правах.
- Сложно разрабатывать и тестировать. На примере той же кафки - подключиться к топику и записать в него что-то через гуй - это отдельный челендж.
- Запросы должны быть небольшими (сотни кб)
Сложный
