REST или очередь сообщений в многоуровневой гетерогенной системе?

Я разрабатываю REST API для трехуровневой системы, такой как: Client application-> Front-end API cloud server-> user's home API server (Home).

Homeявляется домашним устройством и должен поддерживать соединение Front-endчерез Websocket или длительный опрос (это первое место, где мы нарушаем REST. В дальнейшем это становится еще хуже) . Front-endв основном туннелирует Clientзапросы к Homeсоединению и обрабатывает некоторые вызовы сама. Иногда Homeотправляет уведомления Client.

Front-endи Homeимеют в основном один и тот же API; Clientможет быть подключение к Homeнапрямую через локальную сеть. В этом случае Homeнеобходимо зарегистрировать некоторые Clientдействия на Front-endсебя.

Плюсы для REST в этой системе:

• ОТДЫХ читается человеком;
• REST имеет четко определенное отображение глаголов (например, CRUD), существительных и кодов ответов на объекты протокола;
• Он работает по HTTP и передает все возможные прокси;

REST контрастами являются:

• Нам нужен не только стиль общения запрос-ответ, но и публикация-подписка;
• Коды ошибок HTTP могут быть недостаточны для обработки трехуровневых ошибок связи; Front-endможет вернуться 202 Acceptedк какому-либо асинхронному вызову только для того, чтобы узнать, что необходимое Homeсоединение разорвано и должно было быть 503;
• Homeнеобходимо отправлять сообщения Client. Clientпридется опрашивать Front-endили поддерживать связь.

Мы рассматриваем WAMP / Autobahn через Websocket, чтобы получить функциональность публикации / подписки, когда меня поразило, что это уже похоже на очередь сообщений.

Стоит ли оценивать своего рода очередь сообщений как транспорт?

Похоже, что очереди сообщений:

• Мне нужно самому определить глаголы CRUD и коды ошибок на уровне сообщений.
• Я читал кое-что о «более высокой стоимости обслуживания», но что это значит?

Насколько серьезны эти соображения?

Если у вас есть возможность подключения, используйте очередь сообщений - хотя вы должны определить свои собственные протоколы (вряд ли это трудная задача!) Для отправки сообщений определенной структуры и формата.

Проблема с обслуживанием заключается в том, что обычно клиент и сервер строятся отдельно, поэтому вам нужно быть осторожным, чтобы оба конца использовали одинаковые определения сообщений, но если вы недостаточно организованы, просто используйте тот же XML, который вы использовали бы в своем REST. служба.

Если у вас есть проблемы с подключением через Интернет, только с портом 80 и http и «однонаправленной» связью, то, вероятно, лучше всего использовать систему в стиле REST. Отправляйте и опрашивайте или получайте веб-сокет для данных обратного вызова, но, как правило, разработчик вашей системы будет клиент / сервер. Если у вас есть возможность получить подключение, то системы обмена сообщениями - это хорошо.

Я бы выбрал ZeroMQ для системы обмена сообщениями, достаточно настраиваемой, чтобы ее можно было использовать в любых сценариях, включая отказоустойчивые. Я не уверен, что это работает через http, хотя.

Похоже, автобан прекрасно вписывается в то, что вы пытаетесь сделать. Есть и другие доступные инструменты. Ознакомьтесь с сервисной шиной Windows Azure (в которой есть клиентские платформы для Java, .NET, PHP, Python, NodeJS и Ruby).

Пока встроенные сообщения об отдыхе полезны. Вы обнаружите, что ваше приложение перерастет основные операции CRUD. Например, если ваша заявка была банковской системой. Вместо

Обновить Acct 54321 Баланс = Баланс - 20.00 Обновить Acct 98765 Баланс = Баланс + 20.00

Вы, вероятно, хотели бы одно сообщение, как

Перевод 20,00 со счета 54321 на счет 98765

Лучше, чтобы вы обнаружили это препятствие с REST сейчас, а не позже. Ознакомьтесь с Event Centric от Greg Young, в котором рассказывается, как создать более богатую модель для обмена сообщениями в вашем приложении.