Здравствуйте, frontsquat, Вы писали:

F>Задался таким вопросом (в скобках уточнение, что именно интересует). В моей задаче сервер должен уметь в реальном времени сообщать всем клиентам об определенных событиях. Причем определенный вид таких событий должен быть подтвержден человеком-оператором на стороне клиента. И до момента такого подтверждения, событие должно передаваться даже вновь подключившимся клиентам (которые на момент возникновения события были отключены). Сюда же можно отнести всякие труднопрогнозируемые неприятности в виде падений клиента(ов) или даже сервера. Это не должно позволить событию остаться незамеченным. И вот пришла идея попробовать применить MQ. Что теряю в этом случае? Наверно возможность реализации тонкого клиента, что легко позволяет делать REST. Но взамен получаю надежный асинхронный двунаправленный канал связи. В случае же REST, нужно каким-то образом самому реализовывать server push (будет это long polling или WebSocket). Можно ли в общем сделать такой вывод, что если требуется классический клиент-сервер работающий по схеме запрос-ответ, то однозначно выбираем REST; но если нужна двухсторонняя надежная связь, то MQ будет наиболее гибким решением, пусть и в ущерб простоте создания тонких клиентов? Или я что-то упускаю из виду?

RabbitMQ коротко имеет следующие преимущества — высокая надежность/устойчивость сервера MQ, кластеризация/репликация нод MQ. Для обмена сообщениями между MQ и клиентом используется AMQP-протокол для гарантии доставки сообщения, маршрутизации и т.д. Этих преимуществ нет у обычного web service — он не надежен (особенно в w3wp-процессе) с точки зрения доставки, не масштабируется, но позволяет просто организовать обмен сообщениями (в т.ч. и long pooling если гарантия доставки не важна). Отсюда и следует делать выбор