Помимо асинхронного/синхронного характера конкретной проблемы и с учетом того, что MOM (в данном случае выбрав JMS) предлагают бесплатные дополнительные функции, такие как распределение нагрузки и другие, что еще можно учитывать при выборе JMS, а не REST или наоборот?
Спасибо
Всегда используйте REST. Это самый современный, продвинутый и масштабируемый интеграционный подход, доступный сегодня. Балансировка нагрузки службы на основе REST достигается просто с помощью аппаратного или программного HTTP-балансировщика нагрузки и может считаться столь же свободным, как и балансировка нагрузки в JMS.
MOM (ориентированное на сообщения промежуточное ПО) не масштабируется легко (но может масштабироваться достаточно для ваших нужд). REST работает в масштабе сети.
В MOM нет эффекта масштаба. Для запросов на получение данных каждый раз, когда запрашивается конкретная часть данных, другое сообщение должно быть отправлено на сервер и на него отвечает сервер. В системе на основе REST запросы на одни и те же данные могут обслуживаться с помощью HTTP-кеша. Это означает, что по мере увеличения объема запросов с течением времени система на основе MOM увидит увеличение загрузки сервера с той же скоростью, что и запросы. Система на основе REST увидит увеличение загрузки сервера с меньшей скоростью, чем запросы.
MOM соблазнит вас сообщениями о пожаре и забывании с гарантированной доставкой, только чтобы укусить вас с проблемой цепочки поставок .
MOM ужасен для синхронного запроса-ответа, так как он будет терпеть неудачу (т.е. ждать таймаута), когда сервер не работает. Когда запрос будет терпеть неудачу, вы хотите, чтобы он быстро провалился. HTTP-запрос к службе на основе REST будет немедленно сбой (при подключении TCP), если сервер не работает.
MOM полезен для асинхронного обмена сообщениями "запрос-ответ", но тогда вам останется проблема с тем, где хранить состояние между запросом и ответом (подсказка: ваши параметры Файл или обычная база данных, Сообщение или База данных NoSQL). Часто дополнительные усилия по осуществлению не стоят ощутимых преимуществ асинхронности. Также службы на основе REST поддерживают асинхронные запросы, если вам это действительно нужно. 202 Принято является вашим другом в этой ситуации.
Наконец, использование кеширования позволяет основанным на REST системам реализовывать интеграцию на основе pull-based, которые намного легче поддерживать. Например, просто скажите, что мы хотим переместить данные из системы A в систему B. Подход MOM должен был отправлять сообщения от A до B. Подход, основанный на REST, заключался бы в создании службы передачи данных в (например, в RSS-канале) что B опроса для новых данных (так же, как ваш RSS-ридер публикует опросы для новых статей). Когда B терпит неудачу, в примере MOM команде поддержки необходимо будет следить за очередями сообщений, чтобы убедиться, что они не переполняются, а кто-то другой получает B обратно. В примере REST команда поддержки просто должна беспокоиться о том, чтобы вернуть B. Когда A терпит неудачу, нет большой разницы. В примере MOM B не знает и не заботится. В примере REST B знает, что A не работает, но все равно все равно, потому что, очевидно, нет новых данных от A, когда он работает. Первоначально опрос, основанный на использовании pull-based интеграции, требует, чтобы швы были очень неэффективными, однако HTTP-кеширование делает это не проблемой.
Другими словами, вместо того, чтобы инвестировать в JMS-сервер, инвестируйте в хороший балансировщик нагрузки HTTP-кеширования.
Вы не можете сравнить эти две технологии.
REST - это сервис/шаблон, который предоставляет вам организованный способ доступа к ресурсам без сохранения состояния.
MOM Systems/JMS - это шаблон, разработанный для обмена сообщениями между системами. Речь идет о данных, надежных данных.
Вы не можете реально сравнить JMS с REST, потому что они решают разные проблемы.
Но если ваш вопрос больше похож на то, нужен ли мне REST-интерфейс для моих очередей JMS? В этой ситуации я видел, как люди используют REST для защиты тонких клиентов от необходимости логики ставить сообщения в очередь в JMS. Например, если у вас есть клиент Android, который хочет общаться на JMS, сделать это гораздо сложнее, чем отправлять сообщения в интерфейс "отдыха", который затем может переводить и передавать в JMS.